The path to continuous deployment - Òscar Vilaplana¶

Tags: django, djangocon

If you’ve got continuous deployment, you’ve got stable servers. You make big changes in small increments.

Continuous deployment forces you to do many good things:

• Good tests.

• Repeatable build.

• Well-configured identical machines.

• Automated deployment.

• Migrations and rollbacks

• Etc.

Lots of good things. But let’s compare it with lion taming.

Originally, lions were beaten into submission, confused and kept in line with whips. Likewise you’ll be beaten if you dare to touch the production machine as it might break.

Now lions are understood better. Conditioning, behavior/signal mapping, reward and trust are the methods now. We understand that deployment is hard. We have behaviour/signal mapping with code/test/green/deploy. Etc.

• Continuous deployment: everyone is responsible. Everyone deploys. You automatically learn. Everybody uses the same environment locally for test deployments. The same as on the server.

• Testing is core. Slow tests are killing. Fast tests. And all types of tests: unit, functional and acceptance tests. Also automatic code checkers. The light must stay green. Quality must stay high, also test quality.

• You need a repeatable build. And it should include not just code, but also configuration and infrastructure. And… always follow the pipeline.

  Even in emergencies, follow the pipeline. Peer review, tests, and then the deployment. Don’t do manual steps.

• Rollback. You must be able to switch back to the previous version.

  You can take a canary approach. Canary in the coalmine. Show the new version to a few users. “User testing” in a sense.

  Rollbacks in databases; keep it backwards compatible. Never drop columns, for instance. (After a long time, you can remove them safely, of course).

• Small changes. Frequent releases mean less risk: if something breaks, you know where to search.

Some tips:

• Split your stuff in components. A component is something that has a good API and that can be switched out for a different component. It can also be separately deployed.

  This helps with testing, too.

• Rehearse releases. Get very good at them!

• You need good infrastructure. You must manage it and test it good.

• Keep all environments equal. Use vagrant.

• Automate everything! And if it is not possible: document it. But know that that’s something that’s not quite correct yet!