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.

The issue I run into is the following:

Product A: offers an API on several environments DEV/TST/ACC/PRD

Product B: wants to use ProductA-TST on DEV/TST/QA
wants to use ProductA-PRD on ACC/PRD

I want the ability to make a library set of varables from product A so any other product I have can easily link to the API, without having to keep track of a url in the other projects variables. So if Product A changes the URL, everyone is automatically updated.

But I might have more environments in other projects or want to map multiple environments to 1 environment of product A.

Currently the only way for me to do this is to hardcode the url and set it up for all environments:
ProductAUrl: producta-dev.company.com Environments: dev/dev2
producta-tst.company.com Environemnts tst/tst2
ect
While otherwise I could use something like
producta-#{environment).company.com

So what I would like if there was some way to map different environments between products or a way to select a variable for a specific environment.

1. ProductB DEV/TST/QA -> ProductA TST
2. ProductB variable: #{ProductAUrl | TST} Scope: DEV/TST/QA

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

Hi,

The overview page seems to show a variable amount of releases. On one project it is showing 4, where only the oldest and newest deployments were pushed to prod. On another project it is only showing 3, again where the oldest and newest were to production.

Could we simplify this and just have it show a paginated list of all the releases? You could then use the filters to filter the rows down (rather than columns as it does now, which isn't a filter if we're honest!).

By doing this it will make this screen much more usable in terms of getting a quick overview of what went out where and when. Releases page doesn't help because I have to drill into each and every release to see where it went.

Thanks

We have dev and prod instances of Octopus Deploy. I’ve created a deployment project on the dev and then we needed to copy it to prod. We didn’t find Export/Import buttons in project UI. My colleague opened https://octopus.com/docs/api-and-integration/octo.exe-command-line/export page and told, that it’s too complicated and it will be easier to manually duplicate all steps on the prod Octopus Deploy.

Could you please add to project Octopus UI Export/Import buttons , that will provide same behaviour as octo.exe CLI. It’s ok to implement just the simplest scenario with default parameters and have a note “if you need more control, use octo.exe export“

Similar requests in the past
https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/6677232-allow-option-to-export-import-project-steps-only
https://help.octopus.com/t/export-import-octopus-project-between-different-octopus-deploy-servers/3550
https://help.octopus.com/t/copying-a-project-between-two-octopus-servers/7453/5

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.