Blue/Green Deployment For Your Web Apps

image for article

Do you want to know how you can apply Blue/Green deployment to your Ruby on Rails, Django, or NodeJS apps and make them backward compatible to your database schema changes? It is possible.

We decided to write this article due to a lot of questions people ask about the deployment and release process and how to improve it. No single solution fits all. It depends on what you would like your release process to be, on your organization’s maturity and readiness to use Continuous Integration (CI), Continuous Delivery or Continuous Deployment (CD).

Let’s clarify what Blue/Green, Continuous Integration, Continuous Delivery, and Continuous Deployment is and what it is not, before turning to the question of how you can tell which one is the right deployment option for you. Finally, we’ll conclude with some best practices for deployment no matter which route you choose.

Blue/Green

Essentially, Blue/Green is a process when you have two app releases running at the same time: one with the old code (Blue) and another one with the new features (Green). When the “green” infrastructure passes the post-deployment testing phase, then and only then is the “blue” infrastructure shut down. This process allows you to make quick rollbacks without interruption or downtime.

Image alt

The Blue/Green release process is software release pattern which aims to shorten time-to-market for the new features, removes the burden on teams to release the code and eliminates the possibility of a mistake by making the release process fully automated. However, not all businesses can benefit from it and, for those who can, the process must be rigorously thought through.

Options for integration and deployment

You probably already use Continuous Integration in your release process.

Image alt

CI is a process of automatically testing and building your code when you change it. It is a process where everyone on the team is concentrated on integrating and stabilizing the system. For example, if someone were to push new code to a feature branch on your centralized repository, then a trigger would automatically initiate automatic testing of the system and build artifacts. And if you use Docker in your app, then this process would finalize by automatically running tests, creating your container, and publishing it to a container repository.

Image alt

Continuous Delivery is based on Continuous Integration and involves semi-automatic deployments. It is semi-automatic because it requires a formal or informal approval process to deliver a new code. An example might be when you have a «Deploy» button in the CI (such as Jenkins, the automation server) with the ability to deploy your app artifacts.

Image alt

Continuous Deployment is based on Continuous Integration as well and is a fully automated process. Some people think it is a release of every change, but it is not. It is a process to automatically deploy your code to production when and only when it is ready for production. Thus, it requires quite a few additional considerations in combination with application development. More about this in the following section.

Deploying your app’s code with Blue/Green

In Blue/Green deployment both of your app versions must support new database schema. So to say, when you migrate your database to conform to a code changes, your old application version must be backward compatible. Sometimes this is not a trivial task, especially if you do not have robust migration process in place and use Relational Database Management Systems (RDMS) like PostgreSQL, MySQL, or Microsoft SQL Server.

Ruby on Rails and Django both have robust migration strategies. However, each framework has a very specific data migration philosophy. For example, in Rails you can do ‘rollback’ to a previous database schema, but in Django all database changes are incremental. Using dynamically typed languages such as Python, Ruby or JavaScript allows you to relatively easy deal with your app backward compatibility issues.

Things get more complicated if you remove fields in your database as part of your new code. In this case, it is a challenge to achieve backward compatibility for apps that are backed by NoSQL databases as well, such as MongoDB, Redis, AWS DynamoDB, etc. Our recommendation would be to stub your fields on the application level and add an intermediate step to remove those stabs during the next build and release. You can use this technique for either Ruby on Rails, Django, Nodejs, EmberJs apps, and others.

Is Blue/Green Deployment right for you?

Most likely, yes. But it must be applied thoughtfully.

There are some exceptions to this general rule. For example, it may not be the best choice if you have complex data migration processes such that your databases are isolated within your app environment and data sharing isn’t feasible, or if your app needs to be aware when it is deployed to initiate some sequential business processes. Blue/Green may add more moving parts in the release process that can break or unneeded overhead.

Conclusion

Each deployment process involves a different strategy and requires a careful review of your operations. Our recommendation is to have a solid testing and QA phrase both before and after deployment before you start thinking about moving toward Blue/Green deployments. We believe software release is an evolutionary process; it does not have to be revolutionary because it must adjust to your current needs.

Here are some good practices to start with:

  • Regularly review your release process and look for places for improvements.
  • Adopt infrastructure-as-code practice for your application and CD configuration code.
  • Have explicit pre-release and post-release automated tests.
  • Have an integration/tooling team, even if those are the same people from your development team.
  • No long-running feature branches, no manual testing.
  • Use CI for every code change your team makes.
  • Make sure your tests are up to date.
  • Make the release review process an unobtrusive and explicit step for the release.
  • Invest your time and effort in CI/CD processes and seek for ways to evolve.
  • Name your releases, make tags and keep track of standard metrics for your incremental development.