- Principle 1: Low-Risk Releases Are Incremental
- Principle 2: Decouple Deployment and Release
- Principle 3: Focus on Reducing Batch Size
- Principle 4: Optimize for Resilience
- Conclusions
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Principle 2: Decouple Deployment and Release
Blue-green deployments and canary releasing are examples of applying the second of my four principles: decoupling deployment and release. Deployment is what happens when you install some version of your software into a particular environment (the production environment is often implied). Release is when you make a system or some part of it (for example, a feature) available to users.
You can—and should—deploy your software to its production environment before you make it available to users, so that you can perform smoke testing and any other tasks such as waiting for caches to warm up. The job of smoke tests is to make sure that the deployment was successful, and in particular to test that the configuration settings (such as database connection strings) for the production environment are correct.
Dark launching is the practice of deploying the very first version of a service into its production environment, well before release, so that you can soak test it and find any bugs before you make its functionality available to users. The term was coined by Facebook to describe its technique for proving out its chat service: "Facebook pages would make connections to the chat servers, query for presence information and simulate message sends without a single UI element drawn on the page." When they were ready to release the chat service, they simply changed the HTML to point to the JavaScript which held the real UI. "Rolling back" would have involved simply changing back to the previous JavaScript.
However, as our systems evolve, it would be nice to have a way to decouple the deployment of a new version of our software from the release of the features within it. In this way, we can deploy new versions of our software continuously, completely independently of the decision as to which features are available to which users. Feature toggles can perform this function. As Chuck Rossi described, Facebook developed a tool called "Gatekeeper" that works with Facebook's feature toggles to control who can see which features at runtime. For example, they can roll out a particular feature to only 10% of users, or only women under 25. This design allows them to test features on small groups of users and get feedback before a more general rollout. Similar techniques can be used for A/B testing.
Feature toggles also enable you to degrade your service under load gracefully—as Facebook did when launching usernames—and to switch off problematic new features if bugs are discovered in them, rather than rolling back the release by redeploying the previous version.