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 interventions 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, DBAs!). 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

Creating happy deployments at more than 25,000 companies, including:

Shout out to @OctopusDeploy for making their software so easy to work with. Just upgraded a 2 year out of date instance and migrated it to a new server and it worked with no effort beyond what their documentation said to do.

Twitter user Alex Dent Alex Dent
@DevOpsDent

We've been overhauling our internal infrastructure and back-end systems over the past month, including a move back to full @OctopusDeploy deployments; rediscovering how nice it is to have a platform-agnostic orchestrator that can deploy practically anything, anywhere ❤

Twitter user Nicholas Blumhardt Nicholas Blumhardt
@nblumhardt

Tools like @OctopusDeploy can be great in enabling culture change, we've been able to scale and improve our configuration story since we started using it https://buff.ly/2JyRmTY

Twitter user Niel Chalk Niel Chalk
@_neilch

Give your team a single place to release, deploy and operate your software.

Octopus Server

Octopus on your infrastructure.
Free for small teams, no time limits.

Download

Octopus Cloud

Octopus hosted by us.
Free 30-day trial.

Get started

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.

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