Presentation given by Joseph Wilk  (co developer of Cucumber, work on Songkick.com) on Tuesday, 29th February

His presentation was about about :

• for sure, continuous integration : build small pieces of work, continuously
• continuous deployment, putting your process in flow.
• Continuous delivery is the addition of those 2 concepts.

As a joke Joseph reminded us how we could do some primal sort of continuous delivery : ssh to the server and edit the files with Vim   change is immediate !

To bring back the fun to software engineering practice, Joseph suggests that the delivery process should be faster (today there are too many barriers with CI, QA, etc..)

Tooling ?

• Heroku is a tool that deploys your code from your SCM, pushes it to prod, restart the server; it is fun but… dangerous .

• Joseph showed us then a tool that, once you save, runs the tests and deploys the code to the live server (why hacking directly with VIM could not work after all ?)

• To add safety, he can also deploy to a different web server, on the same live production machine, but running on a different port : the ability to change and experiment, having a live feedback.

What if some code breaks the site ? does it matter if it is the about page that gets 1% of the traffic, in a month is broken ? you can balance the risks with metrics on your website visits for example.

Thinking bigger : when failure is not an option anymore : if you don’t trust your tests, what can you do to be confident on them so that you are also confident about the quality of the code when your tests is green ? smoke tests, acceptance tests, etc..

Some users want a stable experience visiting your website; others volunteer to beta software : those last ones can accept some broken pages.

Joseph is using at his work a Jenkins CI server to run series of tests : unit tests, acceptance tests (using selenium) recording the run of tests on a flash video file that you can replay. (using a python tool)

With Heroku, you can use a « one button deploy », same thing with Jenkins (anyone in the company can deploy ) it triggers a build that will run the tests before deploying

Joseph also uses Zabbix : to monitor CPU, memory, requests : data that gives you immediate feedback.

Zero downtime releases : no sense to deploy if it takes your website down for 10 minutes

• canary deploy : use your load balancer to redirect 1% of your traffic to the new code
• bug : if you can deploy quicky, then that also means you can fix bugs fast

Joseph asked himself this question from the Poppendieck : how long does it take for a single line of code to be deployed : Joseph was sad to discover that it could be as long as 2 days (he did find 2 days a long time ! !!); a reason for this can be because of all your dependencies : you can try to use libraries (such as rails, will be upgraded every 6 months or so), artifacts (such as ruby gems or debian packages : every machine can get the latest packages from an artifact server) to focus on your business code.

Fast is scary ; but using all this discipline (automated tests running on every commit): fast is fun

 

Q&A :

• can you balance the fun of deploying quickly vs the money you can loose on failure : it depends on your environment, you have to make compromises; tests give you confidence : unit tests, acceptance test, smoke tests; about the infrastructure cost : usually it is not that high; about resources : if you want good developers , you have to help them make their work fun, so continuous deployment can help you hire the best developers
• How long did it take for you to put this infrastructure up : about a year, progressively
• Do you use code coverage : use it as a guidance : you can prefer more fine grained metrics such as logs, parameters permutation with heckle, etc…