Unless you are building a genuine monolith, your projects don't exist in isolation. More and more our industry is moving in a direction where systems are composed of more granular components. Some call it service-oriented architecture, some call it microservices, but the key point from a release-management perspective is that it requires coordination.
Here at Octopus HQ, we love this trend, because frankly, the more moving parts your release and deployment processes have, the more value Octopus brings to the table.
As a natural consequence of this, users want to be able to coordinate the release of multiple projects in Octopus. This is one of our top UserVoice suggestions.
The two key scenarios are:
- Bundle: You want to create a "bundle" release to allow releases of multiple projects to progress together through your environments.
- Dependencies: You want to explicitly model that Project A depends on a particular version of Project B having been deployed.
Introducing the Deploy a Release Step
To solve this problem, we have a created a new step: Deploy a Release. The Deploy a Release step allows you to select another Octopus project to deploy.
When you create a release of a project containing one or more Deploy a Release steps, you can select the release versions of the child projects to be deployed. Exactly as versions of packages are selected when creating a release of projects which contain steps which deploy packages.
The nice thing about implementing this as a step is all the regular Octopus goodness works as expected. You can intersperse Deploy a Release steps with other step types. For example, if you are creating a bundle project then your first step may be a Manual Intervention step (to approve the release), and your final step may be to send a Slack notification. Deploy a Release steps can also be configured to run only for specific environments, channels, or tenants, just as any other step can. They can be configured to run in parallel or serial, just as any other step can.
When a Deploy a Release step is run, it triggers a deployment of the specified project. This deployment is no different from a deployment triggered directly. It will be visible on the Octopus dashboard.
Conditional Deployment
You can configure the conditions under which the child project is deployed:
- Deploy Always (default).
- If the selected release is not the current release in the environment.
- If the selected release has a higher version than the current release in the environment.
This allows you to specify the relationship between versions of your components.
Microservice Example
For example, you are deploying an application, Acme.Shop, which depends on a logging microservice, Acme.Shipping.
The Acme.Shop project could contain a Deploy Release step which was configured to deploy Acme.Shipping with the Deployment Condition field set to If the selected release has a higher version than the current release in the environment.
This would allow the team working on the Acme.Shipping microservice project to work independently, deploying to the Octopus environments when they are ready.
When the team working on Acme.Shop creates a release, they select a version of Acme.Shipping, for example 2.0.0. This effectively specifies the minimum version which must be in each environment. As the Acme.Shop release progresses through the environments, it will trigger a deployment of Acme.Shipping only if the environment doesn't already contain >= 2.0.0 of Acme.Shipping.
Variables
Variables can be passed to the deployments triggered by a Deploy a Release step. These are available to the child deployment process just as any other project variable.
Output variables from deployments triggered by a Deploy a Release step are captured and exposed as output variables on the Deploy a Release step.
This allows output from a child deployment to be used by the parent process and even passed into deployments triggered by subsequent Deploy a Release steps. Many coordination scenarios are enabled by this.
When Can I Get My Hands on It?
This feature will ship with Octopus version 2018.2, which will be released in early February.
Happy (multi-project) Deployments!
Learn more
- Documentation: How to deploy a release in Octopus
- Documentation: Creating a deploy release step as part of your deployment process in Octopus
- Documentation: AWS deployments
- Documentation: Azure deployments
- Blog: Azure PaaS targets with Octopus Deploy
