Lifecycle: Optional phase or optional environment
As a user I would like to have lifecycle phase or environment within a phase be optional.
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.
- 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
This feature was released in version 3.12.8.
Jan Skalicky commented
This is absolute necessity!
Peter Berggreen commented
I like Michael Noonans suggestion.
Another idea would be to add "preconditions" for each phase, so that you could configure from which phases you are allowed to enter another phase. This way you could e.g. specify that it is possible to go to Production from Test and QA, but not Development.
David Keaveny commented
I agree; this would be very useful for me.
Kris Johnson commented
think i duplicated the same question :) it would be a great help for us
Kris Johnson commented
Yes this would be a great help in allowing an optional DEV deployment for us where DEV and UIT are a part of the same phase but we require UIT to always be deployed to before promotion to our SIT EV
As of 3.4 you can define to how many environments on a phase you need to deploy to be able to move on to the next phase. It'll be useful if you could define not just the amount, but a specific environment like:
-- Development (mandatory environment)
-- Test1 (Optional environment)
-- Test2 (Optional environment)
Michael Noonan commented
One possibility for doing this right now (with Octopus 3.2+) is to use Channels. You could create the two lifecycles, one including Test called something like "Normal Lifecycle", and the other excluding Test called something like "Expedited Lifecycle". You could then create two Channels, one called "Normal Channel" and one called "Expedited Channel".
Now you can create your releases in the "Normal Channel", and promote them through Dev -> Test -> QA -> Staging -> Production
or if you want to skip the Test environment, move the release into the "Expedited Channel", and promote it through Dev -> QA -> Staging -> Production.
This way you get a full audit trail of who expedited the release, and you can do it with Octopus right now.
Peter Lanoie commented
We have a scenario that I've explained thoroughly on the support forum:
Basically, we have a tertiary environment that is not nor does it require a life cycle dependency of any other environment. But it should receive deployments of the same releases deployed to environments in the standard life cycle. So in our case, it could be treated as a parallel environment/phase to the first environment/phase in a standard life cycle, essentially supporting optional deployment.
I believe this feature would support our scenario.
David Singleton commented
We only have four phases in our lifecycle- Development, QA, Acceptance and Production. We are using a trunk based development branching strategy where we only branch when we have to hotfix. Even if we branch, we fix it in trunk (still moving forward with the current sprint) and cherry-pick it to the hotfix branch (for that release).
For us, it would be ideal to allow a properly permissioned user the ability to override the phase where a release may initially be deployed (ie, start at the Acceptance Phase in our environment for hotfixes instead of Development), but continue to enforce the phases for promotion.
Shane Ray commented
It would be nice if we could also set a condition based on a variable if the environment of phase should run.
We would like to have a hotfix phase that is skipped during our normal promotion from dev->staging->prod
But if when creating a release we have a variable HotfixEnabled=true or something similar it would allow that phase to process.
Jonas Strandelid commented
We are also in need of a feature like this.
We have 3 phases:
A new release goes through all phases but a patch usually starts with phase 2.
One alternativ for us would be to set an environment as required to pass a phase. In our case I would create two phases:
1. Develop & QA
Environments: Develop, QA (Required)
Environments: Production (Required)
Kevin Callahan commented
We build different environments from different branches (Gitflow - http://nvie.com/posts/a-successful-git-branching-model/). This suggestion might work for us too if we could prevent promotion too.
For example, our deployment to Test is built from Develop. Test should not be promotable to Production. And Staging and Production builds don't go to Test first .
I think the current lifecycle UI would work fine provided the ability to skip an environment and the ability to prevent promotion were added. One way to implement this would be to change the "Required to Progress" option to allow a None/Optional and a Never/Not Allowed choice.
Erwin Staal commented
We have a similar situation. We have four phases which we call RegressionTest, Test, Acceptation, Production. The first phase is used four automated, nightly UI testing. Normally we wait for this result to promote this release to test. Sometimes we just want to skip this phase and deploy to test immediately. So if we could mark this first phase as optional it would be great. That way wou could use octo.exe and specify --deployto=Test