Interview with John Allspaw on continuous delivery
Posted on 01 October 2012
I just finished watching this great interview of John Allspaw on Devops and Continuous Delivery. John Allspaw is SVP of Tech Operations at Etsy.
It’s worth watching the full talk, but here are some of the things I took from it:
Gradually approaching continuous delivery
“We may deploy 20 times a day, but we wouldn’t deploy 20 times a day if we went down 20 times a day. The only reason we got to 20 times a day, is that the first time we deployed 5 times a day, it worked out.”
I have nothing to add to this.
Devops does not mean one big team
I particularly liked the question “What’s the role of operations in an organization that wants to practice devops?” There is an idea floating around that devops means that there should no longer be separate development and operations teams — and while there is a lot of merit in forming cross-functional teams, this doesn’t necessarily mean that we can (or should) do away with operations entirely.
Certainly, product-focussed teams should be taking on a lot of what was traditionally operational responsibility — but they don’t have to take it all on. For example, John describes this process at etsy as freeing the operations from “reactive work” — eg deployments — and allowing them to focus instead on “proactive work” — eg designing infrastructure.
Continuous delivery and database migrations
I have previously been a developer, writing Java code and using dbdeploy to migrate the database schema in line with deploying a new version of code which requires a schema change. I have also been on a more operational team, where I was deploying other people’s ruby code to production using capistrano, where the deploy:migrations target handles database migrations in sync with an application deployment. Database migrations have always made me nervous — they are in general irreversible, and the database is such a core part of the system that a failed migration can be disastrous to try to recover from.
John Allspaw has worked on places that deploy 50 times a day. He has fielded the question “If you deploy 50 times a day, how do you change the database 50 times a day?” The answer is quite simply: you don’t.
He instead describes his previous experience at flickr, where frequent code deployments were enabled by separating code and database deployment. The database is migrated maybe once a week, and the schemas are in place before the code that needs to use those schemas is deployed.
This is one of those obvious-in-hindsight revelations. Working with Clojure has previously encouraged me to look for entangled concerns in code and to decompose code into simple pieces. John’s solution to the database migration problem is the same approach in a different sphere — we want to deploy frequently, but database deployment is risky. Ergo, we should decouple code deployment from database deployment.
That’s what I got from the talk, but he spoke about a whole bunch more topics beyond that. Give it a watch!
Link again: John Allspaw on Devops and Continuous Delivery