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 canand shoulddeploy 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.
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 gracefullyas Facebook did when launching usernamesand to switch off problematic new features if bugs are discovered in them, rather than rolling back the release by redeploying the previous version.