This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-11
Channels
- # beginners (109)
- # boot (61)
- # cider (8)
- # clara (3)
- # cljs-dev (67)
- # cljsrn (5)
- # clojure (96)
- # clojure-argentina (1)
- # clojure-brasil (2)
- # clojure-greece (10)
- # clojure-russia (114)
- # clojure-spec (51)
- # clojure-uk (45)
- # clojurebridge (2)
- # clojurescript (139)
- # cursive (18)
- # data-science (1)
- # datascript (2)
- # datomic (13)
- # dirac (2)
- # emacs (5)
- # events (1)
- # javascript (2)
- # jobs (1)
- # juxt (3)
- # off-topic (62)
- # om (10)
- # onyx (12)
- # perun (7)
- # ring-swagger (7)
- # specter (21)
- # test-check (5)
- # untangled (16)
- # utah-clojurians (1)
- # yada (2)
Morning
Some MORE Clojure-uk action https://twitter.com/juxtpro/status/796999724880498688. Please show some love and RT 🙂 The more CLJ the merrier!
Mostly Ansible, but also where possible minimising server configuration - servers get rebuilt from scratch rather than being upgaded.
korny: is that using containers to isolate most of the setup?
slow for who? servers don’t care 🙂 Our current project tears down and rebuilds the whole environment nightly anyway.
@agile_geek we’re probably going to use containers in the future, right now it’s just microservices
On previous projects we’ve also used Ansible to build images not servers - Ansible + Packer (I think? wasn’t me that built it) to build AMIs, then deploy those AMIs
I like to aim to have the lag between hitting the “deploy” button and being deployed to be measured in seconds
and the lag between updating the master branch and being ready to hit “deploy” to be in seconds too, but no longer than a few minutes
most immutable / build-from-scratch approaches i’ve seen don’t share this goal 🙂
if you build your hosts from scratch and deploy your app in containers on mesos or k8s or w6r that gets you there
I’m mostly talking about building/deploying/phoenixing servers independent of the apps - app deployment for simple changes shouldn’t need a server tear-down. (depending on the scope of the change) - +1 to using containers!
current client is using docker deployed on k8s to achieve this. @glenjamin I agree but I have a problem reconciling build times with automated testing. Obviously test should run as fast as possible but I haven't yet seen a reliable fast way to test UI (events etc.) without firing up a browser a la selenium, which is slow.
@korny - ah, I see. Last few times i’ve done it I’ve also done the app-deploy part using chef/puppet
@agile_geek component isolation, unit testing, extracting logic out of the html part can help build confidence there
“w6r”?
Slow selenium builds IME provide negative value, but a quick run-through of the most important customer journey(s) can be a decent use of selenium imo
There was a decent thoughtworks slide deck I saw about microservice testing which talked about having a test time budget - which I liked the idea of
@glenjamin absolutely but rarely see this and ultimately testing UI behaviour is hard (clicks, scrolling, etc.)
@agile_geek in my last job our client engineers parallelised their UI tests - they still took a few minutes, (and many machines) but it was down from an hour and half to maybe 5 minutes?
@peterwestmacott most places I've worked, including current client, do this. However, UI tests can still run to >10 mins
are there user journeys that legitimately take more than 5 minutes?
i’d be interested to see if anyone has stats on false-negatives vs actual regressions caught in such suites
I’m mostly working on APIs and back-end services, which makes the whole automated test part much easier 🙂 Except when it comes to legacy systems, and semi-legacy code with no good tests
re: false negatives - usual to see fragile tests breaking in these scenarios so would definitely be interesting.
There’s a lot of “it depends” in all this. If a UI failure means a few users see a glitched UI for a few minutes, and you have gradual blue/green deployment to a subset of users, and you can trivially switch back to the previous UI, and you have good monitoring to identify the glitches quickly, then you can get away with a lot less testing. If a UI failure means an outage that brings down multiple systems and gets you onto the front page of the news, then you might need more testing...
korny: agree but predicated on glitched UI bieng detected within the rollout and/or fast rollback. All gr8 goals to achieve BTW
true but I'm advocating a bit of both. Although I'd prefer to keep selenium to a minimum...or do away with it altogether but that comes back to having a viable alternative.
@agile_geek or anyone with access - I have a pull request for http://londonclojurians.org if someone can review please https://github.com/ldnclj/ldnclj.github.com/pull/16
That was quick, its no wonder http://style.com hired you 🙂
Naw... more like 18 months of code reviews at Lloyds meaning I'm conditioned to respond to a PR (or gerrit review) like a Pavlovian dog!
@agile_geek I'll have you barking like crazy in December then when I start sending lots of PR's for the website 🙂
@jr0cket Been barking for years