Octopus Deploy Lifecycles
Octopus Deploy Lifecycles allow for a high level of control in your deployments. The relationship between a project and a Lifecyle is summarized below.
- A project can only be deployed to environments defined in their assigned Lifecycle.
- A project can have only one Lifecycle.
Lifecycles in Octopus consist of a collection of environments and the rules for promotion between these environments. You start with one Lifecycle called “Default Lifecycle”. By convention Octopus will place all of the Environments in the “Default Lifecycle”. In fact, any newly created Lifecycle will have all Environments added by default. You can view your lifecycles under the Library tab in the menu.
The Default Lifecycle will consist of all of the Environments you have defined. For example, if you make Dev, Test, and Prod environments then you will see the following under Default Lifecyle. There is really nothing special about the Default Lifecycle.
You can customize the Environments in a Lifecycle by adding Phases. Adding a Phase will override the default convention of having all the Environments in a Lifecycle.
This part can be confusing the first time you see it. For example, if you want the Default Lifecyle to be Dev -> Prod instead of Dev -> Test -> Prod you might try to remove the Test part of the Lifecycle. This is wrong! Instead, customize the Lifecycle by adding a Phase. Inside a Phase you can then add Environments. Add a new Phase by clicking the Add Phase button in the Lifecycle page.
Clicking the “Add phase” button will bring up an inline edit box as shown in the screenshot below.
Once you add a new phase you can add Environments to the Phase. You could limit the Default Lifecycle, for example, to just two environments. Click the “Add environment” button to add the Dev and Prod Environments.
Click “Save” to persist the changes you made to the Lifecycle. You can see the customized Lifecycle below.
Use Cases for Lifecycles
A Lifecycle limits the environments a Project can be deployed to so this enables several scenarios:
- deployment promotion control
- custom lifecycles for different project types
Deployment Promotion Control
A common use case for Lifecycles would be for ensuring your app goes through Development, Test, and Acceptance before going to Production. Given the following environments shown in the picture below you can enforce that your app goes through Development, Test, and Acceptance before Production with a custom Lifecycle.
First, create a new Lifecycle called “Development/Test/Acceptance/Production”. Then in the first Phase add the Development, Test, and Acceptance Environments by clicking the “Add environment” button. You can make them all required by setting the “Required to progress” textbox to 3.
Custom Lifecycles for Different Project Types
Often times you will have some internal or support type apps that don’t need your full Project Lifecycle. Your main project may need a complex Lifecycle like Development -> Test -> Acceptance -> Production so you have quality releases for your customer base. An internal business app may not need the same level of quality assurance and could use a simpler Lifecycle such as Acceptance -> Production. This will help minimize resources needed for these simpler internal projects.
Protip: Octopus Sandbox
The dead 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.
1) Search for Octopus Deploy in the Marketplace as shown in the picture below.
2) Fill out the wizard and create an Octopus Deploy instance.
It will take about 5 minutes to complete the form and then about 10 more for the resources to be automatically generated in Azure.