Using manual intervention steps as part of an approval process

Automated deployments with... people?

While fully automated deployment is a great goal, not every step in a deployment can be automated, and sometimes a human needs to get involved.

Try it free Learn more

Pre- and post-deploy approvals

Use manual intervention steps in Octopus at the start or end of your deployment to have people from different teams verify and approve the deployment, either before it begins or after it succeeds.

Require that a human intervene during any stage of your deployment process

Verification and canary deployments

Use manual inteventions in the middle of a deployment to have a human check that the system is working as expected, before proceeding with the deployment. If something is wrong, they can enter a reason and fail the deployment.

Humans are the best testing tool at your disposal, so take advantage of a human eyeballing your testing content prior to deployment to prod environments

Things that can't be automated

Some things can be time consuming to automate, and maybe you just haven't gotten around to it, or convinced people that it's safe to automate (we're looking at you, DBA's!). Use manual intervention steps to pause a deployment at any stage and ask a human to do something - like running database change scripts, or dealing with a legacy system - before proceeding.

For extra security, ensure humans approve any number of important stages of the deployment process

Guided failures

Imagine you are halfway through deploying a website to a dozen production servers, when something goes wrong - maybe a file was locked or OS updates caused the machine to reboot. Instead of the whole deployment failing, you can have Octopus pause the deployment and ask for your guidance. You can fix the issue and try again, or skip that machine. Once production is back online you can review the deployment log to figure out why it failed, and prevent it next time.

Fix or skip issues with your deployment steps

Block releases from progressing

Sometimes the deployment is perfect, but you later discover a bug with the app itself - maybe a critical bug or issue that means that release should never be allowed to progress to production. You can mark the release as "blocked" in Octopus to ensure it isn't accidentally promoted.

Block releases you do not wish to be accidentally promoted to prod environments

Welcome! We use cookies and data about how you use our website allow us to improve the website and your experience, and resolve technical errors. Our website uses cookies and shares some of your data with third party analytics companies for these purposes. We do not use these cookies for advertising.

If you decline, we will respect your privacy. A single cookie will be used in your browser to remember your preference.