Blue-Green Deployments

In the previous step we discussed the value of experimentation and creativity. In this step, we look at blue-green deployments. Blue-green deployments are based on two identical production environments. The key is to ensure that the two environments are truly identical, including the data that they manage.

Zero-downtime releases are achieved by deploying to the blue environment. After the new deployment is smoke tested, traffic is routed to the green environment, which then becomes the production environment.

Although blue-green deployments provide a simple and powerful way to test deployment before going into production, they might require production environments of similar size and capacity to perform capacity tests. This might not be an economically feasible option for large-scale services.

This process works for code only. The database is typically a single environment because having two matching databases in which the replica of the active one changes every time you switch requires a complicated setup. The single-database setup requires that the app modify the database on startup so that it works with either version. For more information on blue-green deployments with a single database, see Bozho’s Tech Blog.

Microsoft Azure Web Apps and its staging slots provide an out-of-the-box experience for blue-green deployments. Basically, two deployment slots that can be swapped are provided. In most scenarios, this is the default deployment strategy.

Remember to engage with peers and initiate a discussion where you can practice your understanding. Once you are happy with your contribution, click on Mark as done and we will move onto canary releasing which addresses the challenge of testing a new release.