soap-bubbles-817098_640The most common scenario is that you spent weeks tuning your deployment to production. You suffered through testing and, finally, the end of this release is here. The deployment to production starts… And the application isn’t initializing. Something freezes along your spine as the consequences of this downtime slowly dawn on you…

Does this short story sound familiar? I bet that we all technical chaps suffered through this experience at least once in our lifetime. Then we define rollback plans, contingency interventions, prayers and offerings to the tyrannical data gods… And, in the end, we learn about Blue/Green deployments.

So, what is this about? Let’s picture a basic scenario for what our production environment could be:
BlueGreen1

Simple enough: a server holds an application that attacks to a database, and the users connect to our server. Now, instead of deploying directly, we will publish the new version of our software to a clone of this machine, and redirect part of our user base to this computer. Check the following diagram:
BlueGreen2

If the “green” environment has any defect that prevents the application to start, or there are any errors that automated testing can detect easily, the promotion can be rejected without any impact on our users: they will still be using the version 1.0. However, if it looks like all is correct, we slowly redirect access to our version 1.1.

Take notice on how both versions of our software are using the same database (now highlighted with a third color to make clear enough that it’s not subjected to a single environment). This means that we have to take into account additional considerations when altering the structure, as the current and previous version of the software will coexist for a certain amount of time.

A best practice approach to solve this obstacle is to detach the column or table from the data model in version n, then executing the script that actually removes the element in version n+1. Since there are no “hard links” to the feature, no errors would be generated in any of the blue or green environments when performing deployments.

BlueGreen3

The key to successfully adopt Blue/Green tactics is to automate your environment creation. “Infrastructure as code” approaches that generate your servers on demand on a repeatable and steady form eliminate human error from the equation. Either something as simple as a template for your virtual machine or as complex configuration management and prerequisite inventories allows you to roll out new versions of your product with a minimal collision with your user base.

Oh, and let’s not forget about the mental health of your operations employees. They will be grateful to stop deploying with a sense of impending doom.

Improving your deployments with Blue/Green strategies

One thought on “Improving your deployments with Blue/Green strategies

Leave a Reply

Your email address will not be published. Required fields are marked *