We have environments for Beta and Prod and it looks like Lifecycle is the feature we should benefit from. Normally release goes to Beta and then to Prod.
Question #1: sometimes we may have emergency patches which should be deployed to Prod bypassing Beta. How to do it with Octopus? It is enforcing lifecycle rules and we need to be able to override it somehow.
Question #2: we have transient testing environments which are not really part of the lifecycle. We want to be able to deploy to any of those any time, but it does not make the Release eligible for promotion to Prod. Documentation says that Project can only be deployed to environments listed in its lifecycle. How we deal with those dynamic environments which we cannot even list upfront?
Question #1: sometimes we may have emergency patches which should be deployed to Prod bypassing Beta. How to do it with Octopus? It is enforcing lifecycle rules and we need to be able to override it somehow.
Question #2: we have transient testing environments which are not really part of the lifecycle. We want to be able to deploy to any of those any time, but it does not make the Release eligible for promotion to Prod. Documentation says that Project can only be deployed to environments listed in its lifecycle. How we deal with those dynamic environments which we cannot even list upfront?
To deploy to an environment you have to have it on your lifecycle. What you can do is have a lifecycle that only requires 1 environment to move on to the next phase, but with plenty of other environments on it. Something like:
---Phase1 (required 1 env to move on to the next phase)
Staging (static environment)
Dev1 (transient)
Dev2 (transient)
Feature1 (transient)
Feature2 (transient)
--Phase2
Production
There’s an important gotcha with this approach though: Since you are setting the phase to only require 1 environment before moving on to the next phase, nothing stops you from deploying to Feature1 and then moving to Production while totally skipping Staging. There’s a rather popular uservoice suggestion to make a specific environment the required one that could use some of your votes: https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/8475958-lifecycle-optional-phase-or-optional-environment
Hotfix channel is the adequate answer to the first question. Thank you!
For the second question it looks like lifecycle feature causes more pain than gain. I would like to see environments which are free from lifecycle designation and limitation. We want every developer to be able to create test or repro environments at will and those environments have nothing to do with the lifecycles. They don’t imply any kind of promotions between environments.
As a workaround we can create a lifecycle with just one stage which contains all environments, but it is still inconvenient because 1. we would need to create separate channel for that and create releases for that channel, while all we need is to take default channel release and push it to random environment. 2. We would still need to add (and then remove) all those transient environments to that artificial all inclusive lifecycle, which is extra burden for no gain at all.