Prevent release progression
Sometimes you may need to block your project from deploying a specific release. This is done by preventing the progression of the release.
Preventing progression can be useful if you need to temporarily block the release, or if you need to fix some variables before proceeding. This also allows you to keep releases without deleting them, so they are still available for auditing purposes.
These basic rules are applied when a release is prevented from progressing:
- If a phase has no successful deployments then no deployments to that phase can take place.
- If a phase has only failed deployments, then no deployments to that phase can take place.
- If a phase has a successful deployment, then deployments to any environment in that phase can take place.
- The first phase can always be deployed to even if the release is blocked before any deployment has taken place.
- Optional phases are treated like any other phase and so the above rules apply, even if the previous phase is complete.
- The above rules apply to each Tenant individually with respect to the relevant phase they have reached.
Essentially, a blocked release is about blocking progression to yet to be deployed phases, not about deploying to phases you have already started deploying to. This allows you to, for example, block deployments to the production phase due to a problem uncovered in UAT-1, while still deploying to UAT-2 for further analysis.
You can block a release of a project from being used in any future deployments, no matter which phase the release is currently on. This can be done from the release page of the project you're wishing to block:
Select the option to Prevent Progression:
Provide a reason, so your team is aware and on the same page, and hit Prevent Progression:
Resolve and unblock
When you're happy for the deployment process continuing, go back to the release page of the project, and select "Unblock":
There are two permissions required for the act of preventing progression and unblocking your deployments, which you have to assign to the user performing the task:
- DefectReport: Allows a user to block a release from progressing to the next lifecycle phase.
- DefectResolve: Allows a user to unblock a release so it can progress to the next phase.
What is a defect?
When you block a release from being deployed, we actually use the Octopus API to create a "Defect" for that release with the reason you provided for blocking future Deployments from using that release.
Need support? We're here to help.