Octopus Easy Mode - Blue/green deployments

Blue/green deployments reduce the risk of production outages by maintaining two identical production environments — one labelled blue and one labelled green — where only one serves live traffic at any time. You deploy a new release to the idle environment, validate it, then switch traffic over. If something goes wrong, you can instantly roll back by returning to the previous active environment.

The AWS Well-Architected Framework - Deploy using immutable infrastructure notes that:

Deployments are safer because the previous working version has not been changed. You can roll back to it if errors are detected.

In the previous post, you created a project that demonstrated a progressive rollout through multiple production environments.

In this post, you will create a sample project that demonstrates blue/green deployments.

Return to the series index.

Prerequisites

• An Octopus Cloud account. If you don’t have one, you can sign up for a free trial.
• The Octopus AI Assistant Chrome extension. You can install it from the Chrome Web Store.

Creating the project

Paste the following prompt into the Octopus AI Assistant and run it to create a sample project that deploys an application using the blue/green pattern:

Create a new blue/green deployment project called "19. Blue-Green deployments".

The resulting project models a blue/green deployment strategy for a .NET application running on IIS. The same release is deployed to either a Production - Blue or Production - Green environment on alternate deployments, preventing the same environment from receiving a release twice in a row.

How the blue/green deployment works

Lifecycle

The project creates a custom lifecycle called Blue Green with four phases:

• Development
• Test
• Production Blue (optional) — targets Production - Blue
• Production Green (optional) — targets Production - Green

Both production phases are marked as optional. This means you can promote a release to either blue or green without being required to deploy to the other. The lifecycle enforces the overall promotion path (you must pass through Development and Test before reaching production), but leaves the choice of active production slot flexible.

Deployment steps

The deployment process models the Blue/Green deployment strategy with the Octopus - Check Blue Green Deployment community step template.

This step checks the last successful deployment to either production environment and defines an output variable indicating if the same production environment has been deployed to twice in a row.

The output variable is then consumed by a subsequent step. In this example, the second step is a manual intervention step that warns the user if the same production environment has been deployed twice in a row and requires manual approval to continue.

Towards the end of the deployment process, a step blocks the release from being promoted to the other production environment after a successful deployment, preventing the same release from being deployed to both stacks.

Edge cases

The Blue/Green deployment pattern is a simple concept with a thousand edge cases. It is trivial to imagine scenarios in which the pattern of alternating deployments between the Blue and Green environments must be broken by two sequential deployments to the same production environment.

For this reason, the Octopus - Check Blue Green Deployment step does not block deployments to the same production environment twice in a row. It only produces an output variable that can be consumed by later steps to enforce the desired behavior.

Comparing tenants and environments

This example used environments to represent the blue and green production stacks. It is also possible to use tenants to represent the blue and green stacks. However, there are benefits to using environments:

• Environments are easier to visualize in the Octopus UI
• The ability to block release progression after a successful deployment is only available for environments, not tenants

For these reasons, environments are the recommended approach for modeling blue/green deployments in Octopus.

What just happened?

You created a sample project with:

• Two production environments — Production - Blue and Production - Green — each representing an independent production stack
• A custom lifecycle called Blue Green that promotes releases through Development, Test, and optionally to either production slot
• A validation step that detects and warns when a release is about to be deployed to the same production environment twice in a row, helping to enforce alternating blue/green deployments
• A manual approval gate for all production environments, with a contextual warning if the sequential deployment check fires
• A step that blocks release progression after a successful production deployment, preventing the same release from being deployed to both slots