By default, Octopus will only run one process on each deployment target at a time, queuing the rest. There may be reasons that you need to run multiple, and that’s okay we have a setting for that!
OctopusBypassDeploymentMutex must be set at the project variable stage. It will allow for multiple processes to run at once on the target. Having said that, deployments of the same project to the same environment (and, if applicable, the same tenant) are not able to be run in parallel even when using this variable.
Scoping OctopusBypassDeploymentMutex:
Just like any other Octopus variable, it’s possible to scope the OctopusBypassDeploymentMutex variable. That might be a specific Environment or target role. This can be useful in certain scenarios, for example where you don’t want to run deployments in parallel in lower environments.
Multiple projects
If you require multiple steps to run on a target, by multiple Projects in parallel, you need to add the OctopusBypassDeploymentMutex variable to ALL of your projects.
Caution When this variable is enabled, Octopus will be able to run multiple deployments simultaneously on the same machine. This can cause deployments to fail if the same file is modified more than once at the same time.
If you use OctopusBypassDeploymentMutex, make sure that your projects will not conflict with each other on the same machine.
Max Parallelism
When enabling OctopusBypassDeploymentMutex there are a couple of special variables that may impact the number of parallel tasks that are run.
Octopus.Acquire.MaxParallelism:- This variable limits the maximum number of packages that can be concurrently deployed to multiple targets.
- By default, this is set to
10.
Octopus.Action.MaxParallelism:- This variable limits the maximum number of machines on which the action will concurrently execute.
- By default, this is set to
10. - Note: Some built-in steps have their own concurrent limit and will ignore this value if set. For example the health-check step.
Given five projects with the OctopusBypassDeploymentMutex set as follows:
- Project 1:
True - Project 2:
True - Project 3:
False - Project 4:
True - Project 5:
True
Assuming the deployments for these projects are started in that order, the first two will run in parallel, but the third will wait until they have finished. The last two will then also be blocked until project three completes at which point they both will run in parallel.
Named mutex for shared resources
If you need even more finely grained control to a shared resource, we recommend using a named mutex around the process. To learn more about how you can create a named mutex around a process using PowerShell, see this log file example.
You can see how Octopus uses this technique with the built-in IIS step in the open-source Calamari library.
Help us continuously improve
Please let us know if you have any feedback about this page.
Page updated on Sunday, January 1, 2023