Octopus Deploy Lifecycles allow for a high level of control in deployments. Lifecycles specify rules for promotion between Environments, and retention policies to preserve release versions.
Lifecycles are applied to Projects. A Project can only be deployed to Environments specified in the assigned Lifecycle, and a Project can only have one Lifecycle. These limits restrict the Environments a Project can be deployed to allowing for granular deployment promotion control.
One common use case for Lifecycles is to ensure an artifact is correctly promoted through pre-production environments. This is handled by configuring Lifecycles with rules that determine when and in what order an artifact can be deployed to an Environment.
Every Space starts with one Lifecycle called “Default Lifecycle”. The Default Lifecycle will be automatically applied to every Project. This is sufficient when a single promotion process is needed for every Project. Sometimes there will be internal or support type apps that don’t need the full Project Lifecycle, however. The main project may need a Lifecycle like Development -> Test -> Acceptance -> Production to ensure quality releases for the customer base. An internal tool may not need the same level of quality assurance. A simpler Lifecycle such as Test -> Production will help minimize resources needed for simpler projects.
Phases are the deployment rules that the Lifecycle enforces on a Project. A Lifecycle can be customized by adding Phases. By default Lifecycles will deploy to all Environments.
When editing an existing Lifecycle or creating a new one, select the ‘Add Phase’ button to create a new phase.
The simplest way to fully learn about Octopus Deploy is to create a sandbox instance in Azure. You can quickly create a full Octopus instance from the Azure marketplace.
It will take about 5 minutes to complete the form and then about 10 more for the resources to be automatically generated in Azure.