We are working on making the Add Step functionality much better. The idea is to show built-in steps, community step templates (from http://library.octopus.com/) and custom step templates in one central location. Please let us know what you think by leaving your comment below.

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

Currently there are a few feeds that support v3 NuGet feeds. Octopus currently does not support linking directly to the JSON file. Please add votes and feedback on why you would like this supported by the few feeds that currently do.

Please note that this is not about Octopus updating its NuGet library to support things like SemVer 2.0 which is planned. This is strictly when you add an external feed to retrieve external packages.

When working with the deployment process I sometimes find that I have to do something in a step that might not be standard, for example setting a temporary user on the "create app pool" step. It would then be great to be able to ad a note to the step describing what is done and why.

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).

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

At the moment when editing a step, you can specify which environments it is to be run in. Selecting no environments means that the step will run in all environments. There's no way to specify that a step should run in no environments.

If I have a problematic step and I'd like to take it out of use temporarily while I work on it, I'd like to disable it somehow, maybe with a checkbox on the process page.

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

Run the Octopus server completely on top of PaaS offerings. You could use a Web App site extension to install/run the server (an HttpPlatformHandler might be an easy way to utilize the existing windows service executable), an Azure SQL database for the backend, and a blob storage account could be your NuGet package repository.

It would be nice if I could clone steps inside processes. For example if I want to deploy two nuget packages, I need to create one step to deploy a nuget and again create another step to deploy a nuget, instead of just cloning it. It's a waste of time!

It would be better from a UX perspective if the Project Groups were collapsed by default on the Dashboard. We have 50+ projects and I spend most of my time scrolling down to the bottom of the screen which becomes tiresome.

The ability to filter by status (Failed, Waiting) would also be useful.

I regularly use nested variables to minimise the number of variable changes I must make between environments. Consider something like this:

data source=#{Database.Server};initial catalog=#{Database.Name};#{Database.Auth};

This allows me to just specify simple variables for the DB server, the DB name and the type of auth being used, without having to construct a connectionstring every time (and probably making the odd mistake).

It would be great if I could see the fully-evaluated variables when i click "Show variables" on a release - or at least have a switch between the raw variables and evaluated variables.

I know you have the ability to hide and show environments on your dashboard but my colleagues and I still find it very messy and hard to navigate.

Please would you consider rolling all environments up as a default; something like the mock-up below?

It would be great to see Python listed as a script step. Python is heavily utilized in the infrastructure space, AWS, F5, Citrix, VMware and will help to drive full automation further up the stack.

It could be great to have a place where we can use the tentacles to do some tasks without creating a release.
For example, in my release process I have the backup files and backup DB steps. I would like to be able to launch it without creating a release.
I see it as a new tab "tasks" where you can configure some task as you do for the process and it will appear as a button on the different environment where this task is available.

Via @DotNetWise (https://github.com/OctopusDeploy/Issues/issues/1157)

Retention policy helps you to cleanup the mess, but it could possible destroy your live releases.

You DO want to apply retention policy on live servers, but not for those releases you know there are being used / live etc.

Hence, add the ability to lock a release, so it won't be deleted by the retention policies.
Later on, I could unlock it and it will go away on when the next retention policy is being applied.