How can I set up a blue/green deployment using Octopus Deploy?

[mark.harrison]

In a blue-green deployment model, the production environment changes with each release and there are a few different strategies for implementing the pattern with Octopus Deploy.

Using Octopus Environments

The most common strategy is outlined in our Blue/Green documentation where you create two environments - one for Green, and one for Blue:

In order for you to be able to deploy to either of the two production environments, you will need to configure your Project lifecycle to include both environments in a shared Phase:

When deploying, you can then choose which environment to deploy to - either Production - Blue or Production - Green:

On the Octopus dashboard, you can very clearly see which release is in each of the environments:

One downside is that for each stage of your lifecycle that uses the Blue/Green approach, you will need to create two environments. For example if you were deploying to Development, Testing, and Production you’d need:

• Development - Blue
• Development - Green
• Testing - Blue
• Testing - Green
• Production - Blue
• Production - Green

Another potential drawback is that any Environment-specific variables (like database connection strings) may need to be scoped to 2 environments, the Blue and Green variations.

Using Octopus Multi-tenancy

The other pattern we see is where customers will model their Blue/Green environments using the multi-tenancy feature in Octopus Deploy.

With this setup, you would create tenants, one for Blue, and one for Green:

You can, of course, include any other tenants you like, such as I have with an Internal tenant too. This can be useful where you don’t want to worry about deploying to a Blue or Green set of servers for your own internal testing.

In this scenario, on the dashboard, it keeps your environments nice and clean, one for each of the stages of your deployment lifecycle:

This type of setup can be useful when you are doing Blue/Green deployments in every environment that you are deploying to since you only have one environment modeled in Octopus for each stage. In addition, any variables can be scoped to their respective environment, as opposed to a Blue/Green variation.

However, a drawback with this approach is that on the dashboard overview, you don’t see which tenant (Blue or Green) has been deployed to Production. In the example above I only know that version 2020.07.08.1 is in Production. You’d need to go into the Project Dashboard to find out which tenant it was deployed to.

Using separate folders on a single machine

It might sound simple, but we have seen customers use this technique for blue/green deployments very effectively.

In this case, the blue/green are not separate environments, they are different web sites or services, but the basic premise is exactly the same. The general idea is:

1. Deploy a new instance of your web application and warm it up.
2. Use an on-server reverse-proxy to seamlessly switch new incoming requests to the new instance.
3. Delete the old instance once it has finished processing outstanding requests.

We have an example guide in our documentation on how to achieve blue/green deployments in IIS.

Using Deployment Slots with Azure Web Apps

Although specific to the Azure Cloud provider, Deployment Slots provide a nice way to implement Blue-Green deployments for Azure Web Apps.

This includes the following benefits:

• Reduced downtime when deploying.
• When deploying packages with a large number of files, deployment times can be significantly reduced due to not having to compare with existing files (this assumes you are deploying to a clean slot).
• Rollback can be achieved by simply swapping the slots back.

See our documentation for further details.

Switch Load-Balancer to active Environment

If you are using a load-balancer to switch traffic to the set of machines representing your active environment, we also have a complimentary article on that here:

How can I switch my load balancer to the active environment in a Blue/Green Environment setup in Octopus Deploy?

The exact answer will depend on the type of load balancer you are using. A number of Cloud Providers (e.g. Azure, GCP, AWS) provide ways to interact with the load balancer using their command-line tools. I’ll outline the steps that you can use to switch to your active environment with an AWS Application Load Balancer, but the general concepts will more than likely be transferrable to other load balancer types. Target Groups In AWS, to route traffic to specific EC2 instances, you create target …

A word on databases

Whichever method you look to adopt when implementing Blue/Green in Octopus, or any other tool it’s important to consider the impact of the strategy when it comes to any databases you have. Without a suitable approach, you could find yourself in a sticky situation.

For example, say your application is currently running on the Blue environment. You make changes to a database and the application code which will only work with the newly deployed version on the Green environment.

If you haven’t switched over to Green (as you are still testing your changes), users of your application still running on Blue will face errors with the changes to the database.

A colleague wrote up an excellent article describing some techniques to make blue/green deployments with a database achievable and straightforward:

https://octopus.com/blog/databases-with-blue-green-deployments

Learn More

• Ask Octopus Episode: Blue/Green Deployments
• Deployment patterns blog posts.

Octopus Samples instance

Check out our Samples instance for examples of how to implement the Blue/Green deployment pattern with Octopus!