The Blue-Green Deployment strategy involves having two production environments, as identical as possible. At any time, one of them, blue for instance, is live. As you prepare a new release of your software, you do your final stage of testing in the green environment. Once the software is working in the green environment, you switch the router so all incoming requests now go to the green environment, the blue one is now idle.
1.2. Canary Deployment
Canary deployment is a pattern for rolling out releases to a subset of users or servers. The idea is to first deploy the change to a small subset of servers, test it, and then roll the change out to the rest of the servers. The canary deployment serves as an early warning indicator with less impact on downtime: if the canary deployment fails, the rest of the servers will not be impacted.
1.3. A/B Testing
A/B Testing is essentially an experiment where two or more variants of a page are shown to users at random, and statistical analysis is used to determine which variation performs better for a given conversion goal.
1.4. Rolling Deployment
In a rolling deployment, a new version of the application gradually replaces the previous version by replacing instances of the old version with the new version.
1.5. Feature Toggle
Feature toggles are a powerful technique, allowing teams to modify system behavior without changing code. They fall into various usage categories, and it's important to take that categorization into account when implementing and managing toggles. Toggles introduce complexity. We can keep that complexity in check by using smart toggle implementation practices and appropriate tools to manage our toggle configuration, but we should also aim to constrain the number of toggles in our system.
1.6. Dark Launching
The Dark Launching strategy involves releasing new features to a subset of users, often silently without their knowledge. It allows developers to test features in a real-world environment with actual users. It requires robust monitoring and logging systems to effectively track and analyze the behavior of the new features.
Deployment Strategies
1. Category
1.1. Blue-Green Deployment
The Blue-Green Deployment strategy involves having two production environments, as identical as possible. At any time, one of them, blue for instance, is live. As you prepare a new release of your software, you do your final stage of testing in the green environment. Once the software is working in the green environment, you switch the router so all incoming requests now go to the green environment, the blue one is now idle.
1.2. Canary Deployment
Canary deployment is a pattern for rolling out releases to a subset of users or servers. The idea is to first deploy the change to a small subset of servers, test it, and then roll the change out to the rest of the servers. The canary deployment serves as an early warning indicator with less impact on downtime: if the canary deployment fails, the rest of the servers will not be impacted.
1.3. A/B Testing
A/B Testing is essentially an experiment where two or more variants of a page are shown to users at random, and statistical analysis is used to determine which variation performs better for a given conversion goal.
1.4. Rolling Deployment
In a rolling deployment, a new version of the application gradually replaces the previous version by replacing instances of the old version with the new version.
1.5. Feature Toggle
Feature toggles are a powerful technique, allowing teams to modify system behavior without changing code. They fall into various usage categories, and it's important to take that categorization into account when implementing and managing toggles. Toggles introduce complexity. We can keep that complexity in check by using smart toggle implementation practices and appropriate tools to manage our toggle configuration, but we should also aim to constrain the number of toggles in our system.
1.6. Dark Launching
The Dark Launching strategy involves releasing new features to a subset of users, often silently without their knowledge. It allows developers to test features in a real-world environment with actual users. It requires robust monitoring and logging systems to effectively track and analyze the behavior of the new features.
2. References