From blue to green and back again

Today, developers are much more likely to opt for blue-green deployment, as it is recognised as reducing downtime and risk when releasing new software code

Traditionally, releasing new software code involved deployment of new assets over an existing environment. This can introduce risk, as any issues with the deployment or assets can leave the environment in a broken state, often requiring manual intervention to resolve or even restore from back-up. 

Today, developers – particularly those working on consumer-facing applications or applications with critical uptime requirements - are likely to opt for blue-green deployment, as it is recognised as reducing downtime and risk.

It works by running two identical hardware environments, referred to as blue and green, which are configured in exactly the same way. This means that there is never an environment which is half upgraded and it is seen as offering a cleaner and more reliable way of working. If there are any issues during the process, it is easier to roll back.

At any time, one of the environments is active, while the other is idle or inactive and that’s where the deployments are always done. Both though are identical, with one being known as blue and the other green. If new code is being released, testing takes place in the idle environment, where it is thoroughly tested.

Once testing and verification has taken place, the router is switched, so that this environment goes live and the other becomes idle. If something doesn’t work during testing, it doesn’t matter, as you can try again. The process then reverses when the next new software is ready for release.

Working this way means that switchovers are seamless, because the code has already been running. There is no need to wait for it to compile or warm-up and this reduces downtime, as well as risk.

If you want to find out more about how Lake Solutions can help your organisation with blue-green deployment, then get in touch.

 

Article Details

Ian Jepp
05 March 2020