In Octopus Deploy, what does a Lifecycle control, and how do its phases decide which environment a release may go to next?

## What a lifecycle is for Octopus separates creating a release from deploying it, which immediately raises the governance question: who says a release is allowed into Production yet? The **lifecycle** answers it. A lifecycle is a named, reusable object assigned to a project (or to a channel within a project) that defines the ordered route a release takes through **environments**. It is policy, not process — it says *where a release may go and in what order*, while the project's deployment process says *what happens when it gets there*. Confusing those two is the classic candidate error. ## Phases A lifecycle is a list of **phases**, evaluated in order. Each phase contains one or more environments and three settings that matter in interviews: - **Minimum environments before promotion.** How many environments in this phase need a successful deployment before the next phase unlocks. The value `0` is the trap: it means *all* environments in the phase, not *none*. Setting it to `1` in a phase containing three regional test environments means any one of them succeeding opens the next phase. - **Optional environments.** An environment can be marked optional, meaning a release may be deployed there but never has to be; it does not count toward the minimum and cannot block progression. - **Automatic deployment.** An environment in a phase can be configured so that Octopus deploys to it as soon as a release enters that phase. This is how a team gets hands-off continuous deployment into Dev and Test while the Production phase still waits for a person. Phases also carry **retention policies** — how many releases and how much on-target file history to keep for that phase — so you can hold Production history for a long time and prune Dev aggressively. ## The practical effect Open a freshly created release in a project whose lifecycle is Dev → Test → Production, and the only environment Octopus offers you is Dev. Production is not merely discouraged; it is not selectable. Once Dev succeeds, Test appears. Once Test satisfies the phase minimum, Production appears — usually alongside whatever approval mechanism the deployment process itself imposes, such as a manual intervention step that pauses the deployment for a named team. That is worth separating clearly, because it is the second common muddle. The **lifecycle** gates *whether the environment can be chosen at all*. A **manual intervention step** inside the deployment process gates *the running deployment*, pausing it mid-flight until someone approves. They are complementary: the lifecycle decides eligibility, the intervention step decides whether the eligible deployment proceeds. ## Channels One lifecycle per project would make hotfixes painful — the whole point of a hotfix is that it must reach Production without walking the full route. **Channels** solve this. A channel is a named lane within a project, and a release is created against exactly one channel. A channel can specify: - **Its own lifecycle**, overriding the project default. A `Hotfix` channel can use a lifecycle whose first phase is Production, while the `Default` channel still walks Dev → Test → Production. The normal gate is untouched; you have added a documented, auditable exception rather than a manual override. - **Version rules**, which constrain which package versions a release on that channel may select — typically a version range plus a pre-release tag rule. A `Beta` channel can be restricted to pre-release packages while the default channel takes only stable versions. Because channels are recorded on the release, the audit trail shows not just that something went to Production quickly but that it went via the hotfix lane, which is exactly what a compliance reviewer wants to see. ## Designing them A few judgments recur. Lifecycles are shared objects, so resist creating one per project — a handful of shared lifecycles (`Standard`, `Hotfix`, `Infrastructure`) keeps the policy legible. Use the phase minimum rather than optional environments when you genuinely need N-of-M regional coverage. Reach for a channel, not a second project, when the *route* differs but the deployment steps are the same. And remember that a lifecycle is a guardrail against sequence mistakes, not a security boundary — permissions on environments are what stop the wrong person deploying; the lifecycle stops the wrong *order*. ## Red flags Weak answers describe the lifecycle as cosmetic ordering in the UI, assume you can always force a deployment to any environment, or conflate phases with the steps of the deployment process. Strong answers name the phase minimum semantics (including `0` meaning all), distinguish lifecycle gating from in-deployment approval, and reach for a hotfix channel instead of proposing to edit the lifecycle under pressure.