Octopus Easy Mode - Progressive Rollout

Progressive rollouts allow DevOps teams to deploy a release to a small subset of production users before rolling it out to the entire user base. This approach reduces risk by allowing teams to validate the release in production and catch any issues before they affect all users. Typically, the rollout automatically promotes a new version of an application to increasingly larger percentages of production users, like 10%, 50%, and finally 100%. If there is an error, the rollout is halted.

The AWS Well-Architected framework recommends staggered deployments, noting that:

These techniques contribute to safer and more reliable software deployment and release processes.

In the previous post, you created a project that used a Claude agent step to categorize commits.

In this post, you will create a sample project that demonstrates a progressive rollout through multiple production environments.

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 with a progressive rollout:

Create a new progressive deployment project called "18. Progressive rollout".

The resulting project models a gradual production rollout by promoting the same release through progressively larger slices of production.

The AI Assistant creates a lifecycle with the environments Prod 10, Prod 50, and Prod 100. The lifecycle captures the different stages of the rollout as a percentage of production traffic, enforces the deployment order, and has the project deploy a release to each environment in turn.

How the progressive rollout works

The project creates a custom lifecycle called Progressive with four phases:

• Development
• Prod 10
• Prod 50
• Prod 100

Each lifecycle phase targets a single environment, and the project uses a runbook to explicitly trigger the next deployment after the current one succeeds.

The deployment process starts with a Deploy App step that simulates deploying an application by printing Deploying app to the task log. It is followed by a Simulate Failure step that acts as a validation gate. This step checks the prompted variable Project.SimulateFail, and if it is set to True, the deployment exits with an error and the rollout stops.

If the validation step succeeds, the process runs a community step template called Run Octopus Deploy Runbook. This step starts a runbook named Deploy Release to promote the current release to the next environment. This works around a limitation where Octopus prevents a deployment to the next environment until the current one is complete, so you cannot trigger a deployment to Prod 50 while the Prod 10 deployment is still running. By having a runbook trigger the deployment after a short delay, we can be sure the current deployment has completed before the next one starts.

The Run Octopus Deploy Runbook step is configured to run in the Prod 10 and Prod 50 environments. It dynamically chooses the next environment with the following logic:

• When the current environment is Prod 10, it triggers a deployment to Prod 50
• When the current environment is Prod 50, it triggers a deployment to Prod 100

The step also passes the current release ID into the runbook as the prompted variable Project.Release.Id, ensuring the same release is promoted through each stage of the rollout.

The runbook itself contains a single Sleep step that waits for 60 seconds before using the Octopus API to create the next deployment. This pause allows the current deployment to complete before the next rollout stage begins.

In practice, the rollout looks like this:

• You create a release and deploy it to Development
• You promote the release to Prod 10
• The Run Octopus Deploy Runbook step automatically starts the Deploy Release runbook
• The runbook waits 60 seconds and then creates a deployment of the same release to Prod 50
• When the Prod 50 deployment succeeds, the same pattern is used to create the final deployment to Prod 100
• If there are any failures, the rollout stops

Customizing the rollout

The Deploy Release runbook initiates a deployment to the next production environment after a short delay. This may be customized to instead schedule a deployment at a specific time, which allows the rollout to be paused for a longer period of time before continuing. You could, for example, only roll out to 100% of production traffic during off-peak hours, or after the release has been validated in Prod 50 for a full day.

You may also consider preventing release progression if a deployment fails. This ensures that a failed release cannot be promoted to the next environment until the issue is resolved. A blocked release will also prevent any scheduled deployments from taking place.

Comparing tenants and environments

This example used environments to represent progressive rollouts. It is also possible to use tenants to represent progressive rollouts. However, there are benefits to using environments:

• Environments are easier to visualize in the Octopus UI
• Lifecycles enforce the progression of releases through environments, which in turn progressively advance the rollout
• 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 progressive rollouts in Octopus.

What just happened?

You created a sample project with:

• A custom lifecycle called Progressive that promotes releases through Development, Prod 10, Prod 50, and Prod 100
• A scripted deployment process that simulates an application deployment and then validates the result before continuing
• A prompted variable that can intentionally fail the validation step to stop the rollout
• A community step template that runs a Deploy Release runbook to promote the same release to the next production environment
• A runbook with a delayed API call that chains the rollout from Prod 10 to Prod 50, and then from Prod 50 to Prod 100

What’s next?

The next step is an example of blue/green deployments.