The blue/green deployment is a pattern you can use to run two production systems at once and then switch between the “blue” system and the “green” system. The way this often work in the context of a deployment production line is that the software moves along the single path to production. If there are no errors, it continues until it gets to the pre-production stage. In this stage, it create a complete production system except that it includes the recent commit changes along with any other changes since the last production release. It runs this at production scale while the production system is running and when there’s a business decision to release the software, you switch the DNS between “blue” and “green” or production and pre-production. This is one way of doing a blue/green deployment. Another way to implement this pattern is to slowly roll out changes across your AWS fleet of resources. If you’ve developed a stateless system (at the instance level) so that workloads can horizontally scale, you can incrementally apply changes across your AWS resources.
So, let’s discuss how these steps are performed in the pre-production stage:
First, it’ll automatically launch an environment based on AMI(s) generated in the acceptance stage. Then, it will load a database with data from production. It will ensure the data is in synch with the production database. Then, it’ll apply any database updates – both in structure (for example, DDL) and data (for example, DMG) using versioned data scripts. If you’re using a relational database, you might use a tool like Liquibase to apply the database changes in a controlled and versioned manner.
In AWS, your blue/green deployment, might use tools like Elasticache to store session state, ELB to modify the endpoints, auto scaling to incrementally scale changes between the blue and green environments and Route 53 to modify the DNS endpoints specified in ELB.
If you need your systems to be running at all times, the blue/green deployment – as I’ve described it – is the way to go. If your users can experience some downtime, there are other less complex ways to apply these changes. For example, you might export and import the data from your production database and apply it to the pre-production database and have your database scripts apply the database and data modifications.
In this case, we primarily used Route 53 to switch the ELB endpoints. Let’s have a look:
Go to Jenkins and open the configuration of the blue-green-deployment job. It calls the file. Inside the .sh file it calls the route53switch-elb.rb file. This file uses the AWS Ruby SDK to modifiy the DNS entries using Route 53.
After blue/green switch and after manual verification, you can terminate pre-production environment. Now that the pre-production environment is done, you can click a button to release the software to production.