Imagine you have a connection string variable and you want to update it. You would update the variable and redeploy, however if you made a mistake (edited the wrong variable or the new connection string was not live yet) then you cannot roll back. This is even more of a problem if the variable is sensitive as you can't copy it beforehand.

I would like to be able to version octopus variables, this would include:
- Who
- When
- When deployed
- The ability to roll back/forward.

At the moment we have to source control much of this type work, this obviously negates much of the valuable octopus functionality around environment handling/sensitive variables.

We have nearly a dozen client/WPF projects that primarily consist of backing up a directory and then overwriting it with an updated package (size ranging from 20-350MB). Each of these projects push their packages to 20 remote servers, but the servers cannot host tentacles due to our security policies, so we run the steps from one of our Octopus hosts (via tentacle installed alongside the manager service). This is slow and expensive on the Octopus host, especially when there are many other deploys underway. Worst of all, it forces steps to deploy in serial versus parallel because all steps are running through a single agent.

After reading a bit on workers and worker pools, I thought they might provide a solution for our bottleneck by offloading the work from our Octo servers and enabling parallel deployments. However, after building a pool, I realized worker-enabled steps are seemingly limited to cloud and scripts. If I was pushing these packages to an S3 bucket, I’d be good to go, but I cannot choose a worker pool as the execution location for the ‘Deploy a Package’ steps we are using. I’ve also considered using PS scripts to push these packages around, but we enjoy using built in configuration features to uniquely configure each remote locations files.

Can worker pool support be enabled for the ‘Deploy a Package’ step so I can use workers to push packages to remote Windows servers?

I'd like to assign a manual intervention, or "Approval gate", at the environment level, independent of project.

We have many projects that can be deployed to our environments. The lifecycles these projects can deploy to have a mix of Dev, CI, Test and Production environments. Some important environments require approval before anything can be deployed to them (e.g. QA, PreProd, Production).

At the moment I have to add manual intervention steps to every project that could be deployed to those environments. I also have to make the intervention steps are conditional based on the environments they're going to (i.e. I don't want the intervention to trigger when going to dev environments). This leads to a great deal of maintenance to protect these environments, and if I make a mistake is doesn't "fail safe". I.e. if I mess up the logic, or miss a project, it will skip manual intervention and allow the project to be deployed.

My ideal feature would be to put a manual intervention, or Approval Gate, on an environment, so no matter what project is to be deployed to that environment, I can rest assured it can't succeed without prior approval.

We're using various steps for deployment ('Deploy a package', 'Deploy to IIS') which both have variable substitution options to substitute variables in Web.config/App.config.

During deployment, i've noticed that these substitutions are logged. However, sometimes i see that our sensitive variables are being logged here at 'verbose' level. Other sensitive (and also non-sensitive) variables are obfuscated.

It seems that the deployment process decides by itself based on the name of the variable. In my opinion, the sensitive option of the variabel should be considered here as well.

An example of what we've got currently:
We've got an appsetting in our app.config, lets call it ConfigSetting
In octopus i've defined two variables, ConfigSetting (non-sensitive) and ConfigSettingSecret (sensitive). The secret is retrieved as output of a previous step.

Values are:
ConfigSetting = {Setting1:Value1,Setting2:Value2,Secret:#{ConfigSettingSecret}}
ConfigSettingSecret = #{Octopus.Action[GetSecret].Output}

Now, i've noticed that the ConfigSetting along with the actual secret is logged on variable substitution. Obviously, this should not be logged.

My feature request is therefore to prevent these sensitive variables from being logged.

Exclude process steps when you are creating release not before deploying release. Why?

We have multiple projects and when we are deploying to higher environments we are actually deploying "wrapper project" which contains releases of projects.

In each release, we don't always deploy all the projects so we want to exclude them from deploying.

We know that we can set up "deploy only if the version is greater". But If we exclude some of deploy release steps then we have a better overview of what actually has been deployed.

We just want to skip boring manually clicking each time before deployment to all environments. Also if the deployment fails you need to do it again...

So would be nice when you create release that includes this excluded steps into a snapshot of the release.

Whenever there is a change in the variable after the creation of the release, we used to get warning saying "Release Snapshot has been changed". But we do have only one option to update the entire release without knowing what has been changed. It would be great if you have any way to find/highlight the variables and their values that will be updated when I click "Update Variables" in the release Snapshot section. It will minimize the risk when it's comes to updating the snapshots for production deployment and it will give a transparent view of what changes are done in the variables post release creation.