When working with multiple related projects, it is often necessary to co-ordinate between them and take some action that depends on their combined status. For example, ensure a related project is deployed first or send an email when all projects are deployed. This guide discusses some approaches to this problem and provides some examples showing how to query and control projects programatically.
For in depth code samples covering many of the processes discussed in this guide, see the Project Coordination Code Samples page
Responding to events across multiple projects
There are various ways to respond to events within Octopus, which is useful for:
- Sending an email once a set of projects is deployed
- Generating a report of the day's deployments
- Promoting all projects from one environments to another at a certain time
- Triggering another process, for example another deployment
- Verifying that some conditions have been met
The simplest trigger is a periodic timer setup through a Windows schedules task, Azure Function or as a windows service. Alternatively it can also be a project within Octopus as a project that re-queues itself when run (see the samples).
Octopus 3.5 introduced subscriptions, which can call a web service or send an email when Octopus events occur.
The event can also be a script step in a project. If the script is defined as a step template it can be shared among the related projects. However it is difficult to ensure that two copies of the script do not run at the same time.
Orchestrating the deployment of multiple projects
Below are two different approaches to orchestrating multiple projects. Depending on the projects and requirements, one or a combination of these two approaches may be used. This orchestration is useful for when:
- A set of projects should always be deployed together or in a specific order
- A project depends on a certain version of another project
- A project should not be be deployed while another project is being deployed
- A certain step should not execute at the same time as a step in another project
This approach consists of creating a project that co-ordinates the deployment of other projects and any other related actions. For example it could define steps that
- Deploy and wait for projects A and B
- Send an email informing users Project A and B have been deployed
- Deploy project C
- If the deployment of project C fails, redeploy an older version of A and B
This approach consists of each project taking on the role of checking that the other projects are in the right state so that it can deploy itself. It is usually implemented as one or more script steps. For example the project could:
- Trigger a deployment of Project A if it has not been deployed to the environment
- If Project B is running, wait for it to reach step 3
Deploy Release Step
The Deploy Release step is helpful when implementing the Master project or Cooperating projects approaches described above. It makes it simple to deploy a release of a project from another project.
In This Section
The rest of this section covers these topics in some more detail, and explains how to implement them.