I agree with Anonymous and Kenneth Jespen about it being part of the Lifecycle. If lifecycles included approval steps/gates, that would fit our need *perfectly* and get our DevOps team out of the middle-of-the-night, click-the-button ceremony.

In our development lifecycle (and other enterprise organisations I have worked in) a particular release is identified as a candidate for release to production after it has been deployed to a particular test/qa environment. It is at this point in time where we would like to record the event that the release is approved for deploy to production (and by whom).

One implementation could be an editable property (e.g. "approved-by") associated with a release, and policy associated with an environment that can prevent deploy of a release that does not meet specific criteria (e.g. "approved-by!=null").

We need our QA team to sign off a release before the dev team can deploy the applications to production. Our current process is:
1. TeamCity builds/tests and (if all's good) creates the NuGet package
2. Deploy to Dev Environment is started automatically
3. The Dev team (Group) can Deploy to UAT
4. The QA team can then approve this UAT Release
5. The Dev Team (Group) can now deploy to prod (As UAT has been approved)

Currently, this can be done by using Manual Intervention, but this isn't the correct way to do it. There should be a step between each Environment

This is very important to help enterprise processes to meet their audit and approval processes. Financial institutions are a good example where we cannot begin a production deployment until the appropriate parties have signed off on the deployment. Currently this is not possible without first having our release management team initiate the deployment first. Approvals are really different than interventions at time of deployment. I agree with other suggestions where the approval/sign off steps should be at the life cycle level rather than the project level. I do think you may need to have a setting that allows you to assign projects that are affected/require the sign off for a specific layer of the life cycle.

I would like to support what Anonymous said about having approval as part of the lifecycle. I think this would cover all of these use cases and would help resolve issues where management needs to approve a release before being able to proceed (both for supervised and unsupervised releases).
I'm currently doing this the way Thomas Hørup Ebling talked about, but if a deployment (for whatever reason) fails and you need to "Try again", then you're out of luck.

I wonder whether there ought to be a totally separate manual intervention concept. The current one is great for the "You need to do something manually in the middle of the process" workflow, but the actual concept of approving something feels like it would live more naturally as part of the lifecycle rather than the deployment process. The lifecycle currently defines when it is OK to deploy from one environment to another, and to add to that "and person X has to say it's OK" would make much more sense.

Ditto - we're in the same boat. We want to avoid getting managers out of bed at 4a.m. on a weekend just to have them click a button on an approval step.

It would be superb if this could be implemented soon.

Our use case:
We have two groups that must approve a release before going to Production, GroupA and GroupB. We would like to maintain the current approval steps when doing a 'Deploy now' deployment, as we need both groups to approve. However, when we want to schedule a deployment for off-hours, it would be nice to have both groups approve ahead of time.

We are unable to use the workaround of having an 'approval environment' to gate the release prior to going to Production, as we need the approval to happen per deployment, not per release.

Currently we are looking into writing a custom app that will allow a user to query all scheduled deployments in Octopus, select one for pre-approval, and submit with a comment. This will create a scheduled task to run that will approve the deployment at the specified time. Though not something we'd like to do, it's also better than setting up the VPN and logging in at 2am to approve.

I envision this enhancement would function similar to how scripts can be run prior to package download. Select an option to "run prior to scheduled deployment." If selected, it will leave the 'deploy now' functionality as-is, but will change the 'deploy later' to allow approval anytime before or during the scheduled deployment.

At the moment we are solving this with workarounds. One is having 2 manual steps, one for the approval, and another for the deployment. This requires devops team to be available when the actual deployment is to happen, e.g. 2:00 AM. The second is to use the existing scheduled deployment. The governance team prefers the first option, because they like the idea, that a physical person / persons click the actual deploy button. (DevOps team are of another opinion :-)

So I also support something like the suggest above. E.g. a new standard step called something like "Async Manual Release Approval".

If there is a powershell ninja reading this, perhaps they could suggest a custom step?

Just came across this in my first project going into Live where we want an approver and to use the scheduling ability :(

Why are there so few votes and what do others do in this situation if they're not bothered by this?

Our interest is similar. We would like the approval to happen during business hours and then an unsupervised deployment after hours. We configure emails to identify deployment is starting and then a detailed completion email with each step's status.

Exactly the problem i'm facing.

Just to elaborate on this a bit: I'd like to have an added option, something like: "Pre-Release Task or Approval", to the Manual Intervention steps (and email or see my other idea about adding notification to MI steps: https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/6297235).

For immediate deployments this would have very little impact, but for scheduled releases, when the step gets processed it will run immediately (subject to run order of course!). Doing so would allow you to have a multiple approval steps that run as soon as the release is promoted, but then the actual release steps would hold off till the scheduled time. Some manual intervention steps should only run at deployment so I wouldn't want to make this universal, but configurable for each step.

The scenario I'm look at is to have 3 manual intervention steps for a release.
Step 1: Approval from immediate manager (pre-release)
Step 2: Approval from Stake Holder (pre-release)
Step 3: Engineering ready (at release time)
Step 4-X : Code deploy.

Steps 1 & 2 need to happen during regular business hours, but step 3 should only happen at the time the deployment is scheduled. It's there to ensure that engineering is on site and everyone's ready to supervise the release.