Fork me on GitHub
#clojure-uk
<
2016-11-11
>
jonpither08:11:57

Some MORE Clojure-uk action https://twitter.com/juxtpro/status/796999724880498688. Please show some love and RT 🙂 The more CLJ the merrier!

korny10:11:06

More clojure is good - but tbh I’m kind of over Puppet.

glenjamin10:11:02

what have you moved on to?

korny10:11:30

Mostly Ansible, but also where possible minimising server configuration - servers get rebuilt from scratch rather than being upgaded.

glenjamin10:11:15

but that’s soooo slow!

agile_geek10:11:34

korny: is that using containers to isolate most of the setup?

korny10:11:16

slow for who? servers don’t care 🙂 Our current project tears down and rebuilds the whole environment nightly anyway.

korny10:11:43

@agile_geek we’re probably going to use containers in the future, right now it’s just microservices

korny10:11:55

on standalone machines

korny10:11:53

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

glenjamin10:11:46

I like to aim to have the lag between hitting the “deploy” button and being deployed to be measured in seconds

glenjamin10:11:38

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

glenjamin10:11:59

most immutable / build-from-scratch approaches i’ve seen don’t share this goal 🙂

mccraigmccraig10:11:10

if you build your hosts from scratch and deploy your app in containers on mesos or k8s or w6r that gets you there

korny10:11:17

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!

agile_geek11:11:13

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.

glenjamin11:11:01

@korny - ah, I see. Last few times i’ve done it I’ve also done the app-deploy part using chef/puppet

glenjamin11:11:46

@agile_geek component isolation, unit testing, extracting logic out of the html part can help build confidence there

glenjamin11:11:35

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

glenjamin11:11:15

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

agile_geek11:11:16

@glenjamin absolutely but rarely see this and ultimately testing UI behaviour is hard (clicks, scrolling, etc.)

Rachel Westmacott11:11:19

@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?

agile_geek11:11:21

@peterwestmacott most places I've worked, including current client, do this. However, UI tests can still run to >10 mins

Rachel Westmacott11:11:45

are there user journeys that legitimately take more than 5 minutes?

glenjamin11:11:53

i’d be interested to see if anyone has stats on false-negatives vs actual regressions caught in such suites

korny11:11:55

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

agile_geek11:11:07

re: false negatives - usual to see fragile tests breaking in these scenarios so would definitely be interesting.

korny11:11:31

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...

agile_geek11:11:19

korny: agree but predicated on glitched UI bieng detected within the rollout and/or fast rollback. All gr8 goals to achieve BTW

glenjamin11:11:10

the converse is also predicated on glitched UI being caught by selenium 🙂

agile_geek11:11:43

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.

practicalli-john14:11:08

@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

practicalli-john14:11:55

That was quick, its no wonder http://style.com hired you 🙂

agile_geek14:11:51

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!

practicalli-john21:11:25

@agile_geek I'll have you barking like crazy in December then when I start sending lots of PR's for the website 🙂

agile_geek21:11:57

@jr0cket Been barking for years