Octopus Deploy Lifecycles

November 18, 2016 | Kyle Nunery @knunery

Octopus Deploy Lifecycles allow for a high level of control in your deployments. The relationship between a project and a Lifecyle is summarized below.

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.

Default Lifecycle

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.

Lifecycle Phases

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

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.

It will take about 5 minutes to complete the form and then about 10 more for the resources to be automatically generated in Azure.

The post Octopus Deploy Lifecycles appeared first on Clear Measure.