I suggest you...

Lifecycle: Optional phase or optional environment

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

163 votes
Sign in
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Matthew Beatty shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      • Peter Berggreen commented  ·   ·  Flag as inappropriate

        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.

      • Kris Johnson commented  ·   ·  Flag as inappropriate

        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


      • AdminDalmiro Grañas (Support Engineer, Octopus Deploy) commented  ·   ·  Flag as inappropriate

        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:

        DEV Phase
        -- Development (mandatory environment)
        -- Test1 (Optional environment)
        -- Test2 (Optional environment)

      • Michael Noonan commented  ·   ·  Flag as inappropriate

        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.

        Any thoughts?

      • Peter Lanoie commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        We are also in need of a feature like this.

        We have 3 phases:
        1. Develop
        2. QA
        3. Production

        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)
        2. Production
        Environments: Production (Required)

      • Kevin Callahan commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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

      Feedback and Knowledge Base