Currently, a deployment targets a project and an environment.

Some customers have applications that they host for many customers, with each customer having their own set of configuration options applied. Their application may not be designed to support multi-tenancy, and instead is deployed separately for each customer.

To handle this in Octopus currently, they either duplicate the project many times, or they duplicate environments many times.

We should build in the concept of a "Tenant" as a first class concept that can be enabled. Each Tenant will have a name and a set of associated variables. When deploying a project, you'll be able to choose the Tenants to deploy (since each Tenant might need to run different versions of the application).

It should be possible to handle scenarios where many Tenants run on the same set of machines, or where each Tenant has a different machine.

https://github.com/OctopusDeploy/Issues/issues/256

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

I want to use template-all model, where all projects consists only of step templates, to provide central management of deployment process. But when i modify step template, I need to manually go into every project and into step and click "update".

I think it would be better to use TeamCity model, where template can only be inherited and not changed inside project, or cloned from template if changes needed. Or provide the ability to one-click update all steps that uses the template (even better ask for it after click on Save button).

I'm going to end up with 30+ projects, all using the exact same setup consisting entirely of imported Step Templates. A "Project Template" feature would be hugely helpful; failing that, I need some way of auto-refreshing all imported steps.

There are multiple places within Octopus where you can set 'conditions' on something by limiting it to a set of machines, or environments, etc.

It would be nice if we could extend this UI to allow the 'inverse' to be selected too.

Examples are:

• A step that only runs for a given environment -> users should be able to say "only the X and Y environment" (which they can do now), or "all environments except X and Y" (which they can't)




• Deploying to a subset of machines (advanced deployment settings) - again you can include machines, but not exclude them. If you have hundreds of machines and want to exclude just two, you have to specify the other 98. (has been implemented in 3.7.9 https://github.com/OctopusDeploy/Issues/issues/2854)

Multiple suggestions have come up that asked for something similar - I think if we do this we should do it a little more generically so we have a consistent user experience.

https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/6503490-provide-an-option-to-exclude-machines-from-deploy

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).

At the moment the run condition of a step is based on the success of failure of previous steps. It would be useful if this could be based on custom variable.

In our case, we have a step to check if there are any database changes required, if there are then we take a backup else we don't bother. Whilst this could be all done with in a single step template as there were some already available that did most of what we wanted this process takes three steps in our deployment.

1. compare for differences


2. run backup if differences exist


3. run db upgrade.

The first step sets a variable to indicate whether the next to should run or not. I've then added an extra parameter to these steps to indicate whether they should be run or not and then have some powershell at the start of the steps to check this variable for true or false.

As this powershell is the same across all my steps which require a check to run or now. I figured it might be useful to have this ability within octopus itself.