At the moment (at least to my knowledge) the order in which prompted variables are shown is dependent on the variable name (ordered alphabetically).

It would be really cool if there was a possibility to give prompted variables an explicit order so that we can control in which order they appear in a simpler manner. For example it would be cool if one could just set a "priority" value for a prompted variable. This "priority" could be an integer and the prompts could then be ordered by this priority in descending order.

Unfortunately giving them names to achieve the correct order is problematic since we have some variables that are only prompted in some scopes and therefore it wouldn't really make sense to change their name because another scope needs them to appear in a certain order.

Sometimes when deploying, the user receives this message:

"For consistency, this deployment will use a snapshot of the variables and deployment process that was taken when the release was created, which does not include the latest changes that have been made to the project. A changed process can only be incorporated by creating a new release (this one may be renamed if desired). Variables can be updated via the release page, clicking Show to show the variables from the snapshot, and clicking the Update variables button."

It would be great to be able to tell the user exactly what changed, so they can make a judgement on whether or not to update variables or create a new release.

Ensuring certificates for the OD server are up to date are a little annoying. It would be awesome if the OD server could support renewing it's own hosting certificate with Let's Encrypt.

I've had a stab at creating custom steps to do this. The main issue is domain validation (DV). DNS validation often requires manual intervention and OD server controls http (see discussion at https://community.letsencrypt.org/t/domain-validation/26512 ).

The only way I see this really progressing forward is if OD server supports Let's Encrypt in the server as a maintanence task as it would be able to respond to http DV requests. It could then get the new certificate issued after successful http DV and update its https binding to use the new certificate.

I would also like to have the same thumbprint configured in the registry of the server for RDP access. An option to support this as part of the certificate renewal would be great.

We have many dependencies between our projects. So for example we have cross database dependencies which mean that a particular version of the database must be installed prior to another version. Similarly we have base services that are required by all others that must be installed first. There is currently no way of telling Octopus that one project depends upon another.

We could create one great big Octopus deployment with all the steps in it to deploy the TFS projects/libraries in the correct order. But this would be very complicated because of the large number of dependencies.

It would be great if it was possible to say Project z version a to b depends upon project y version x? So if the user attempts to deploy project z version a through to b without first deploying project y version x. Octopus would automatically deploy project y version x first. Similarly if project y version x itself depends upon another project /version that would be deployed before project y version x. Before a project/version is deployed the list of dependent project/versions that will be deployed could be shown. It would also be great to be able to view a diagram showing the dependency tree between projects.

Cannot find another idea on this forum which describes this so adding new suggestion (original question http://help.octopusdeploy.com/discussions/questions/5627).

The variables view is very basic and it generally needs improving since it quickly gets hard to use when you begin adding lots of variables.

1. You have to add the same variable name for multiple environments and the ordering of environments is not the same. This is error prone and makes the list hard to parse.


2. There is no description for variables so you need to add very long names sometimes. This has already been covered, but I added it for completeness. See https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/6079578-enhance-the-variable-maintenance-screen-with-varia
   


3. There can be different types of variables which are changed for different reasons. It would be great to have a category concept to group them with.


4. For very large numbers of variables it would be great with a search box which filters the variables as you type. It should also search in the description.

See the following mockup for an example:
http://s288.photobucket.com/user/withoutprecedence/media/OD%20variables%20view_zpsfesl13ke.png.html

We would really like to have an option to leave bindings alone in IIS if they already exist.

I configure a single binding as a templated deployment step. I would like octopus to automatically create the IIS app and bindings in the event the app pool and website doesn't exist - but if it does already exist I'd prefer it not to reconfigure the bindings.

This is useful when we create website aliases for production environments which don't fit the normal QA and UAT environment setup (but they happen to use the same steps).

Best would be a checkbox:

"Overwrite any existing bindings" - defaulted to true for backwards compatibility.

Source: http://help.octopusdeploy.com/discussions/questions/2727-deploying-a-site-with-existing-iis-bindings

When you create a release, Octopus default to picking up the latest version of the available packages.

We have multiple forks of our packages, and we need to be able to restrict a package step so that it is limited to a particular version range of the package, for example:-

If we have a major version 1 of a package on a step,

If we later create a fork and do work on a major version 2,

We do not want the next octopus release to pick up major version 2 - we want to limit the scope of the step so that it can not go above major version 2.

NuGet itself supports this concept when specifying package dependencies using notation like:

1.0 = 1.0 ≤ x
(,1.0] = x ≤ 1.0
(,1.0) = x < 1.0
[1.0] = x == 1.0
(1.0) = invalid
(1.0,) = 1.0 < x
(1.0,2.0) = 1.0 < x < 2.0
[1.0,2.0] = 1.0 ≤ x ≤ 2.0
empty = latest version.

If we could specify this on the nuget package step it would great.

At the moment, the way we have to currently handle this is have a seperate nuget feed per major version, which complicates our build and release process and adds a fair bit of overhead.