Introduced in Octopus
2018.2.1, the Deploy Release step allows you to trigger the deployment of a release of a project from another project. This is useful when you are coordinating multiple Projects.
When you add a Deploy Release step to your deployment process, you are then able to select the project which will be deployed.
You can add many Deploy Release steps to your process, if you wish to deploy releases of many projects.
When creating a release of a project containing Deploy Release steps you are able to select the release version of each project, similar to the way versions of packages are selected.
A Deploy Release step can be configured to:
- 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
Variables can be passed to the deployment triggered by the Deploy Release step. These will be made available to steps within the child deployment's process, just like regular project variables. Variables passed in will override existing variables in the child project if the names collide.
You may wish to capture information from a deployment triggered by a Deploy Release step, either to be used in the parent process or to be passed to another deployment via another Deploy Release step.
Any output variables generated by a deployment will be captured as output variables on the Deploy Release step which triggered the deployment. These can then be used by subsequent steps in the process.
These output variables are captured as variables with the following name pattern:
Octopus.Action[Deploy Release Step Name].Output.Deployment[Child Step Name].VariableName
and for machine-specific output variables:
Octopus.Action[Deploy Release Step Name].Output.Deployment[Child Step Name][Machine Name].VariableName
Deploy Release Step Name: The name of the Deploy Release step in the parent process.
Child Step Name: The name of the step in the child deployment process which set the output variable.
VariableName: The original name of the output variable. e.g. for
Set-OctopusVariable -Name "Foo" -Value "Bar" this would be
Machine Name: The machine the child process was targetting when the output variable was set.
For example, you have a project Project Voltron which contains a Deploy Release step named Deploy Red Lion which triggers a deployment of another project Project Red Lion.
Project Red Lion contains a step Echo Paladin which sets an output variable. e.g.
Set-OctopusVariable -Name "Paladin" -Value "Lance"
This variable will be available in subsequent steps of the Project Voltron process via the variable
Octopus.Action[Deploy Red Lion].Output.Deployment[Echo Paladin].Paladin.
The Lifecycles of project's being deployed by a Deploy Release step must be compatible with the coordinating project.
For example, if you have two projects,
Project A and
Project B which are referenced by Deploy Release steps in another project
Project Alphabet. When deploying
Project Alphabet to the
Test environment, the release versions chosen for
Project A and
Project B must be eligible to be deployed to the
Test environment according to the lifecycles of those projects.
When it is a tenanted project being deployed by Deploy Release step, then the parent project should also be created as tenanted.
When triggering a tenanted deployment of the parent project, the tenant will be used to trigger the child deployment.
If the child project is untenanted, and the parent project is deployed with a tenant selected, then the untenanted child project will simply be deployed, ignoring the tenant.
Deploying a Combination of Tenanted and Untenanted Projects
A project can contain multiple Deploy Release steps which deploy a combination of tenanted and untenanted projects. There are a number of approaches which can be used to control which Deploy Release steps will be executed.
- Scope the Deploy Release step to one or more tenants. This is useful if the child project should only be deployed for particular tenants.
- If the child project is untenanted, and should only be deployed once for all tenants, then the Deployment Conditions can be used to specify that is should only be deployed if the version does not match. This will prevent it from being deployed multiple times if multiple tenanted-deployments of the parent project are created.