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
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:
- Deploy a new instance of your web application and warm it up.
- Use an on-server reverse-proxy to seamlessly switch new incoming requests to the new instance.
- 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:
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
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:
Octopus Samples instance
Check out our Samples instance for examples of how to implement the Blue/Green deployment pattern with Octopus!