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?

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.

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.

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.

When we deploy a website we need to grant the user running the IIS application pool access to the deployment directory. Similarly, when deploying a windows service, we need to grant the user running the service filesystem permissions to the deployment directory.

It would be great to add a Feature to "Deploy to IIS" and "Deploy to a Windows Service" that would set the file system permissions for the user associated with the App Pool or Windows Service.

We like to set file system permissions during deployments so we have one less environment-specific issue to worry about (ex: oops, the user running the service in the test environment had file system permissions but the one in production did not causing the application to fail in production).

This issue is particularly important with the "Deploy to a Windows Service". The service will not start until the file system permissions are granted for the user running the service. So we have to use 4 steps instead of 1:
1. Deploy a Windows Service (startup set to manual)
2. Grant file system permissions (using a community step template)
3. Set the Windows Service Startup Type to automatic (using a community step template)
4. Start the Windows Service (using a community step template)

This is a lot of complexity for deploying a windows service and it would be much better if the "Deploy a Windows Service" process worked in this order:
1. Deploy the package & extract
2. Grant file system permissions on the installation directory
3. Install & start the windows service

Have a scenario where I need to deploy the same package multiple times **on the same set of servers** under different custom directories and different IIS web applications. There are role scoped variables which get picked up for custom installation directory and also appsettings.

I understand that the documentation under https://octopus.com/docs/key-concepts/machine-roles clearly states:

"This means that the step will only execute on Tentacles with at least one of those roles. This does not mean that if the step is scoped to multiple roles that it will run for each role. Instead it will run that step for all machines that have any roles that match any of the step roles."

This would be fine if target machines have only one of the roles which are assigned to the same step. The only way to get this working the way I want it is by cloning the steps and assigning one role per cloned step. As you can imagine, it can get rather long.

Would be great to have octopus loop the same step if it finds that multiple of its roles are assigned to a same target machine AND role scoped variables are defined.