Lifecycles and Environments

Lifecycles control the order of release promotion through different stages or environments in your pipeline. You can configure a lifecycle to require deployments to development, test, and staging prior to deployments to production. They are also used to set retention policies (how long releases are saved) at a per-environment level.

Octopus Deploy shares Lifecycles across an entire space. A project references lifecycles via channels and can reference 1 to N lifecycles.

Lifecycles contain 1 to N phases, representing a stage in your deployment lifecycle. A phase can have 0 to N environments; for example, you could have a test phase that contains both development and test environments. Or, you could have a development phase for your development environment and a test phase for your test environment.

Manually set your phases

A lifecycle with no phases will result in Octopus calculating the phases automatically for you containing all environments. The order of the phases is dependent on the order of the environments on the environment page.

We recommend manually configuring the phases in your lifecycles, including the default lifecycle.

• No surprises on the order of environments for your release.
• Much more performant, Octopus doesn’t have to try to calculate the phases for you.
• Control over which phases are optional and retention policies.

Number of lifecycles

Your lifecycles should match your branching strategy. For example, you create a feature branch for new work; then once it is accepted, it is merged into main. That specific feature branch will never make it to production. Your lifecycles should reflect that.

Suppose you have the typical set of environments, development, test (or QA), staging (or Pre-prod/UAT), and production with a feature-branch branching style. In that case, our recommendation is to have at least two lifecycles.

• Development or Default lifecycle for feature branches: development ➜ test
• Release lifecycle for the main branch: staging ➜ production

Two lifecycles allow you to have your standard workflow, where all the feature branch work goes to development and test. Once the work is finished and merged into main, the code goes directly to staging and then production.

We never recommend having a lifecycle with only production. Any deployment to production must deploy to at least one other environment to verify the fix. Skipping straight to production, especially during an emergency, will make a bad situation worse.

Production approval

Do not use the manual intervention for business owner approvals, CAB (change approval board) approvals, or other Production approvals unless there is no other option. There are multiple reasons for this.

• The manual intervention step was designed to pause a deployment to allow a person to review something before proceeding. For example, a DBA needs to review a database delta script before the database deployment runs, or a QA engineer needs to manually verify the new code version before all traffic is redirected to that version in the load balancer.
• The manual intervention step was not designed to handle complex approval rules. For example, a person who triggered the deployment isn’t the person approving the change, or anyone involved in the code changes cannot approve the deployment to production.
• The manual intervention step runs during a deployment. That requires you to first start the deployment to production to approve the deployment in production. This prevents scenarios where you can schedule a deployment at 4 PM to run at 2 AM the next day.

We recommend leveraging the ITSM functionality that integrates with ServiceNow or JIRA Service Management. The ITSM integration is designed with production approvals in mind. You can get approval and schedule a deployment to production at 4 PM to run at 2 AM the next day. The approval workflow must be completed prior to the deployment starting. And the approval can follow the rules you built into the ITSM provider.

If you cannot leverage ITSM integration, we recommend two approaches to production approvals. These are listed in order of precedence.

1. Restrict who can deploy to production to your operations or systems admins. Ensure they cannot make changes to the deployment process. When they click the deploy button, that is their “approval” to deploy to production. See common RBAC scenarios on how to set that up.
2. Add a prod approval environment to your lifecycle. An example lifecycle with a prod approval environment is development ➜ test ➜ staging ➜ prod approval ➜ production.

The prod approval environment has all the manual intervention steps required for approval. After the release is “deployed” to the prod approval environment, it can then be scheduled for a production deployment. No manual intervention steps will be required in production as all approvals happened earlier.

Automatic and optional phases

Each phase has two different deployment options:

• Manual: a release must be manually deployed to this phase.
• Automatic: a release is automatically deployed to the phase as soon as it is ready.

An automatic phase is similar to a database trigger; the logic is hidden unless the user knows the visual cue. If you want to use automatic phases, our recommendation is to make it a standard across all lifecycles. Or, clearly name the lifecycle to indicate it has automatic phases.

Each phase can also be required or optional.

• Required: at least one environment must have a successful deployment before the release can proceed.
• Optional: the release can skip this phase.

We recommend having at least one required phase before a production environment.

Further reading

For further reading on lifecycles and environments in Octopus Deploy, please see:

• Lifecycles
• Environments
• Channels

Help us continuously improve

Please let us know if you have any feedback about this page.

Send feedback

Page updated on Wednesday, October 4, 2023