Continuous Deployment Variables and Solutions
Paul Biggar, co-founder of CircleCI, presented on "the many ways to deploy continuously" at RubyConf 2013 in April of this year. The frequency at which deployments happen qualifies the term "continuous" and directly influences the deployment problem space. The presentation aggregates solution information gathered from CircleCI's own customer base, Facebook, IMVU, Etsy, Heroku, and Google. They found that every company does deployment slightly differently and that there isn't just one solution for deploying continuously.
Paul shared details about how deployment solutions are going to have processes involving code, databases changes, units of deployment, deployment speed, testing, and monitoring. He said the variables affecting the development of these deployment solutions include speed of new features, code complexity, software architecture, software design, number of engineers, and the state of monitoring.
Paul explained that the most common solution to managing the transition state during deployment to production, the "Race", was to deploy code that supports new and old functionality. This requires engineers to program functionality so that new code can safely run side by side with old code. Databases present an additional challenge of stored state. At first it seems like updating everything else in the application first and allowing the app to handle both versions of a database would be enough, before ultimately changing the version of the database. However In some cases changing SQL databases causes so much locking that the only reasonable choice is to create a new database table for each version and migrate the data out of band. The application would be coded to check for the new table and fall back to the old table if the data is not present. NoSQL has become popular in part because it can avoid the locking scenario.
The presentation covers additional aspects of deployment including unit of deployment, speed, validation through testing, and verification through monitoring. While these are non-functional requirements of deployment, the level of these capabilities determine to what degree deployment is continuous.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015