Sometimes deployments are bad due to bad configuration variables that are un-testable before releasing to production.
Having the ability to 'dry run' a deployment and see all the task outputs with specific highlighting for variables and evaluated variables would allow the identification of changes that need to be made before actually deploying to an environment.

Add RO attribute/flag to variable set to prevent accidentally changes of it. Or even develop extended permissions linked to username, groups etc. For example in our Octopus environment we have default variable set in library for special package and I'm afraid if somebody will change it accidentally and it will affect to whole related projects where it will be used

Make it possible to put environments into groups (or rather, to put Tentacles within an environment into groups)

https://github.com/OctopusDeploy/Issues/issues/497

It would be great to have the ability to be able to add an approval step for a scheduled deployment, but be able to approve it before the deployment starts.

So for example, if I wanted to schedule a deployment to run at 2am, I have the ability to schedule the deployment, but the approval can happen between now and then, but the rest of the steps only run at 2am.

Source: http://help.octopusdeploy.com/discussions/questions/3081

When working with library variable sets used in many projects with many steps it is cumbersome to figure out where a given variable is used.

When updating a deployment process, certain tasks become very difficult, such as:
-Renaming or deleting a variable
-Checking validity of a newly-updated variable value across all usages

With a "find all" feature these tasks would be much simpler (plus I'm sure there would be wider-reaching benefits).

I think it would be a nice feature to be able to rename roles, there are situation where you might choose the wrong name and at that point if you have many project connected to it it will be annoying to have to update all the projects.

It would be really nice if Octopus Server (and portal) had the ability to be updated the same way as a release can be pushed meaning through and Octopus nuget package. this would make the maintenance easy instead of having to download and rerun installer each time a new Octopus release is created

Now when a step failed you have to set guided failure on in order to retry the step, it would be handy to have a setting where you say always retry failed steps.

For example if you are doing continues deployment where a build server triggers a deployment from a build, you have to:
- login into octopus
- select the correct project
- manually intervene and assign it to you
- retry it

It would be much better if the retry can be done automatically

It would be helpful to be able to specify multiple channels for automatic release creation. The way we are using channels, no package is eligible for more than 1 channel. Without this, the development team now needs to remember that for some channels they don't need to go to octopus to create the release and for others they do.

Currently the new IIS step (introduced in 3.4.7) allows you to create Sites, Apps and Virtual directories, but you always have to deploy a package.

It might be useful for some users to be able to take advantage of the IIS functionalities, without having a deploy a package.

Source: http://help.octopusdeploy.com/discussions/questions/9702

When a release is automatically created from a package push to the private NuGet feed, it would be handy if the release notes from the release was generated from the combination of release notes in each of the packages in the release.

We need to use C# code as script in the script modules

While we can run smoke tests by using the PostDeploy.ps1, such as running nunit.exe or something similar (frisby.js, etc), it would be great to have a way to integrate back into the dashboard (through the rest api?).

Related links:
http://help.octopusdeploy.com/discussions/questions/214-running-smoke-tests-after-deploy
http://help.octopusdeploy.com/discussions/problems/53646

http://jimblogdog.blogspot.co.uk/2012/08/walk-thru-using-wolfpack-to.html

Currently the automatic release creation feature does not resolve variables when looking if a package is used in a project set for automatic release creation. You can only use package IDs with static names.

It would be great if you could use variables in the package ID and have them resolved when the package is pushed.

Source: http://help.octopusdeploy.com/discussions/problems/28069

Some of our projects live on shared servers, and run under different users for isolation. It would be good to be able to choose which user a nuget deployment/powershell script runs under so we can protect against mistakes/malicious code in our powershell deployment scripts.

There should be the possibility to create project templates which can be chossen when creating a new project. This should then not only copy everything, but keep the reference to the template. So when something is changed in the template, all projects based on this template should be updated as well.

Steps coming from a template should not be editable in a subproject, but there should be the possibility to disable a specific step in a specific project.
Also there should be the possibility to add other steps between "template steps" to customize the process.

Teamcity has a simillar model.