What is a Blue/Green Deployment?
Just in case you are not familiar with the term and the practice, Blue/Green Deployments are one of the two most popular ways (Canary Deployments are the other one) of deploying new functionality in a CI/CD and DevOps process.
Blue/Green Deployment processes are typically used under the following circumstances:
- The environment is small enough so that it is possible to maintain two entirely separate instances of the environment. One is referred to as the “Blue” instance, and one is referred to as the “Green” instance. At any moment in time, one of them is the production instance, and the other contains the most recent changes that are currently being tested and are next to be put into production.
- The rate of change is usually not more than once a day or once a week, since flipping the entire environment between two instances of it more frequently than daily or weekly can be impractical.
So, as mentioned above, the way that deployment works in a Blue/Green case is that, for example, Blue is the production instance, Green contains the most recent updates, and when testing and verification of Green is complete the production load is cut over (redirected) from Blue to Green. They everyone holds their breath, some people pray, and everyone just hopes that it works. If it does not work, then the redirect of the load is reversed and Blue becomes the production instance again. The DevOps and Development teams then go back and try to figure out what went wrong when Green went live and the cut over is tried again once everyone believes that the issues have been addressed.
Why Do Blue/Green Deployments Fail?
Blue/Green Deployments fail for pretty much the same reasons that deployments of new functionality in software have failed since the start of the modern software industry:
- A clear understanding does not exist between the business constituents for the software and the technical team as to what the new release should do. So when it goes into production, the business constituents try to use it, and determine that it does not meet their needs.
- Verification that all of the previously existing functionality (regression testing) is not comprehensive enough (it never actually covers the entire waterfront, now does it?), and things that used to work, no longer do.
- Verification of the new functionality in the release or update turns out to have been incomplete and all of the new functionality is either not present, or does not work as expected.
SafeDeploy Eliminates Blue/Green Deployment Failures
SafeDeploy takes a unique approach to helping DevOps and CI/CD teams eliminate problems with Blue/Green Deploys. SafeDeploy captures the entire activity stream of the application while it is in production (Blue in this case). That activity stream is then “played back” against the new instance of the application (Green in this case) which verifies that all of the functionality that existed and works in the Blue instance of the application, now works in the Green instance of the application. This eliminates the need for regression testing, and eliminates all of the problems associated with incomplete regression testing.
SafeDeploy’s Role in the Blue/Green Deployment Process