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.

When you navigate to a project, you get to the Overview page as a start. When you open up many projects at once (cause a change triggered multiple CI for example, which should be deployed) all of them will show "Overview - Octopus Deploy" in the HTML title and as such it's also what's displayed on the browser tabs:

You loose the ability to distinguish between these tabs. It also means that if you bookmark multiple projects then you'll have to change their title manually to have a valuable label for them. You have to click around them to figure out which tab is which.

What I'm proposing here is to take a look at titles generally around the product and make them as short and describing as you can. Start with the projects if it's possible, as I think that's the most frequently used parts.

Few examples:

1.) Overview - Product.Vertical.ServiceType.ServiceName - Octopus Deploy
2.) Overview - Product.Vertical.ServiceType.ServiceName (The icon should be enough to identify that it's Octopus Deploy)

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.

Amazon's ECR (Elastic Container Registry) is a docker-compatible registry that you can configure as a first-class package feed in Octopus. Part of the ECR product (in AWS) is to set up lifecycle policies so it can automatically delete old images (since it takes up space for each image). This is a similar feature that Octopus offers on its own built-in package registry, but the ECR is obviously an external registry so the purging has to managed by AWS (and no Octopus). But ECR has no way of knowing which images are used (so they won't get deleted), except if you specify a new tag on the used images (like deploy-Stage for example), then you can exclude those.
Currently I can do that with a custom step, but it would be nice (since ECR is a 1st class feed now) to have a checkbox that would do this automatically in Octopus so it would be easier for users to enable this.

We have an service environment right now that consists of two data centers that each contains 3 servers that host the services. These services hosts host 100+ services each and each server is hosting exactly one instance of each service; so they are in effect mirrored.

When we deploy to these servers, we do it one data center at a time. Since there are so many services per server, we can’t just remove the server from the load balancer. Also since we do round robin load balancing and want to have zero downtime and keep consistency in our responses during deployments we create a rule in the load balancer to redirect traffic to the service to the opposing data center.

Our problem is that to define this behavior, we’ve had to effectively define two environments for each actual environment. One for DC-1 and another for DC-2.

If we were able to tag the machines with a role which corresponded to their respective data center and could do a rolling deployment per role, that would really help with the clutter in our Octopus deploy dashboard.