Presently Octopus assumes the deployment environment must exist before the project is setup - because you can't create a deployment that targets a role that doesn't exist.

This means that you can get into creating your new deployment, then realize you are blocked from saving, then lose your changes as you a) go and create a role or b) go and talk to the admin (the drop-down won't refresh, so creating the role in a different browser tab doesn't work).

I think it'd be better if you were just warned if targeting a role that didn't exist, but allowed to save and create the deployment anyway. The net result would be no different from if the deployment were orphaned due to the tentacle being removed after the deployment is created - ie there is no new edge-case here.

This would make it explicit that you can create the environment and the deployments in any order you like.

As a user I would like to have lifecycle phase or environment within a phase be optional.

Use Case:
We have dev test environment which our devs can test stuff before sending it to QA but they are not required to and only usually do so for more complex stories. They also sometimes do ...interesting things with that environment. They need to be able to deploy without restriction or impact on state of other environments.

Our QAs however are required to deploy to QA before deploying to staging/prerelease.

Possible solutions:
- Optional phase
- Optional environment in phase that does not count in required deploys
- Ability to add environments to lifecycle that aren't in a phase

Allow the use of variables within other variables. I understand this could become problematic if abused (circular references, etc). However, I think this would greatly simplify administration of large projects/variable sets. For example:

{Administration.Service1Uri} = "http://myhost/service1"

{Administration.Service2Uri} = "http://myhost/service2"

etc...

This could be change to

{Administration.Service1Uri} = "#{Administration.BaseUri}/service1"

{Administration.Service2Uri} = "#{Administration.BaseUri}/service2"

These variable now become target netrual, meaning they don't need to be duplicated when a new target is introduced. Simply duplicate #{Administration.BaseUri} for the new target, and the rest will just fall into place.

Another example would be database connection strings, which typically are identical over all environments/targets with the exception of the username/password. It would be much more simple if you could declare a target neutral connection string, the reference #{DbUsername} and #{DbPassword} within it.

If we currently look in the current uservoice we will find many items regarding "Azure AD support", "Crowd SSO" or even "Two factor auth". I honestly thing that a simple way to enable those scenarios is to add an extensibility point for authentication mechanism.

This will allow custom authentication (not AD or user/pass) be handled separately and advance in their own. I can see many scenarios around this, including teams and external handling of users with custom databases.

For example, in our organisation we handle developer teams around the Github organisation so when a new user arrives it is just matter of adding the user to the organisation (and now adding the user with a different password to Octopus).

Other apps has taken the same approach, Teamcity, Jira, etc...

Short version:

Have the Write-Warning command in Powershell to trigger a warning in a step and write the warning message.

Long version:

I would like an easy way to write change a step's state to pass with warning. I understand that the current workaround is to use Write-Error with the [-ErrorAction Continue] option, but this also seems unnatural because it prints error messages in red, whereas I would prefer to just write warning messages in orange.

The Write-Warning command in powershell seems like an intuitive candidate to achieve this, as it technically doesn't write to StdOut but StdWarning (can be redirected with 3>), so it would seem feasible to detect warning messages.

The other reason I would like this is that my company parses Octopus's console output for words like "Error" because we don't want those to go through the cracks, and so using Write-Error is too aggressive of an option for me.

Thanks!

We have this scenario: after internal testing is completed (on multiple environments), the next phase in our lifecycle involves manually deploying to 2 environments - QA and Demo.

Circumstances may dictate that either QA or Demo can't be deployed to immediately, so there's no guaranteed order and timing for these deployments to occur.

The following phase is Production, which of course can only go ahead after QA is completed.

So here's our problem:
a) If we specify that "All environments must be deployed to before progressing to the next phase", we can't move to Production until Demo is also upgraded.
b) If we opt for "Required to progess = 1", and Demo is deployed to before QA, we may have Production upgraded before QA.

In short, it would be great if there was a way to specify which environment(s) must precede the next phase, rather than just "a number of".