Help me understand the impact of setting OctopusBypassDeploymentMutex

Legacy Uncategorised
1

Hi,
We currently have 40 projects with each one having its own tentacle running on the octopus server. Most of the projects have a nuget that is specific to that project but there are a few that share a nuget. Most of the projects deploy to an azure instance. To make life simpler we are thinking about setting OctopusBypassDeploymentMutex and moving to 1 tentacle to rule them all but im not clear what the risk of this is and would hate to do the work to have to roll everything back. What conflicts and i likely to run in to? Is there something that would tell me if im a good or bad use case for this setting? Does the behavior of this setting change in Octopus 3 in a way that could impact my decision.
Thanks
tim

2

Hi Tim,

Thanks for getting in touch! As I have been trying to answer this question, I have three very important questions that I need answered first to really respond:

  1. Are all of these ‘machines’ in their own environments
  2. How often to do you deployments simultaneously to these machines?
    2a. How many at once (maximum)
  3. What step types do you currently have for these projects?

Answering these questions will allow me to come up with the correct issues, instead of making poor assumptions and typing lots of words that turn out to not matter.
Vanessa

3 
  1.  There is one tentacle per project, each project has between 3 and 7 environments. If moving to one tentacle per environment would make a difference we would be open to that.

  2.  Right now its rare that a project would kick off to more than one environment but it does happen. We run lots of deploys in a day and if we had one tentacle for all or one tentacle per environment there would be a lot of overlap in deployments, particularly in dev and prod.

a. At an environment level In dev I have seen as many as 10 at once, at a project level I have seen as many as 3 at once but 2 is far more normal IF it happens

  1.  Most project send an email, deploy to azure, vip swap, send an email, delete staging, run a clean up task (doesn’t do much at the moment) A few of the deployments run powershell scripts to run db scrips, configure iis, update cscfgs with ACL entries.

Hope that answers the questions sufficiently.
Thanks
tim

4

Hi Tim,

Based on all the information I don’t think you will have many issues at all.
Octopus will have some issues using the bypass variable when it needs to do things such as update IIS because it can lock files.
But you would also see this using your method if the IIS bindings files were unavailable for access.
This can also be an issue depending on what your PowerShell scripts do and if they also access/write to particular files, but again you would have seen it already.

I would suggest starting with a handful of projects (your most complicated ones, in an environment like dev). However you will have to add the variable to all projects as if one without the variable deploys at the same time, it will break the current deployments.

Vanessa

5

Thanks Vanessa,
It till take some time for us to really test this but ill let you know how it goes.
Thanks
tim

6

Hi Tim,

If you are planning on upgrading to 3.0 I might suggest waiting until after then as we have done some work on Azure endpoints and processes.

Vanessa

7

The guidance suggests to add this variable to the project. Is it possible to inherit the variable by adding it to a variable set and including that in a project?

8

Slandshaw - Totally possible.