I’m trying to set the Start Trigger for some child steps so that they run in parallel. I see the warning, have looked at the linked documentation, and also set the OctopusBypassDeploymentMutex variable to True.
After saving the changes, the configuration settings are reverted back to the default setting. Can I get some clarity on how to utilize this option please? Is the behavior I’m seeing a bug in the UI or am I doing something completely wrong?
My objective is to run a series of Deploy a Release steps to the same role in parallel. These Deploy a Release steps are child steps within a rolling deployment due to other required orchestration.
Thank you for getting in touch! Great questions, and my apologies for the confusion we’ve caused with this experience.
I’ve been able to reproduce this, however only when this option is set on the first step in the deployment process (or within a child step defined within the first parent step). In the case of this issue on the first step, the bug is in the fact that this option is surfaced at all in that context; i.e. this option doesn’t really make sense in the context of the first step. I’ve raised a bug report at the following link. Could you confirm this matches your scenario as well?
Unfortunately I don’t think this scenario would work, as child steps were designed to tackle a slightly different need, e.g. the child steps allow you to run a series of steps on one target, before moving onto the next target to run that same series of steps. There’s no way to configure multiple child steps to run in parallel with each other.
The best approach might be to split these Deploy a Release steps you need to be run in parallel into their own separate standalone steps, then set the Run in parallel with the previous step on each applicable step. That sounds like it might not be possible though, so I’m wondering if you could expand a bit on those requirements, and your scenario?
I hope this helps in some way, and please let me know how you go or if you have any further questions!
Thanks for checking, and yes, I can confirm that my test project only had 1 parent step with child steps that I was trying to configure to run in parallel. I cloned that set of set of steps and as you discovered, the setting seems to stick when I configure it on the 2nd set of child steps.
As for what I’m trying to accomplish. I have a massive chain deployment that needs to be orchestrated as a rolling deployment. Moving the Deploy a Release steps to individual steps would break away from the orchestration that is critical. Running these deployments in parallel is not required, I’m simply trying to find sensible ways to speed up a deployment process that otherwise takes a couple of hours to rollout.
Consider the example below, but imagine having multiple servers and dozens of packages that need to be deployed to each of those servers. Keeping the system online while we deploy these packages is required so I cannot open up the rolling window too much without creating a noticeable impact to the clients.
Thanks for following up, confirming that and expanding on your scenario. Firstly just a quick note that the issue I linked you to was in fact a duplicate of the following bug report. Good news is the fix for it is already set to be included in the upcoming 2020.6.0 release.
As far as a way to better model your scenario by speeding up the deployment time and to fit it in your requirements, I’m sorry to say I can’t see a way to improve the example you detailed. I raised this question internally, i.e. to get ideas on how to model this better, and if supporting the option of grouping a subset of child steps to run in parallel with each other is something we could consider. I can see how that feature/enhancement could really help in a scenario like this, so I’ll certainly let you know if any good ideas come out.
Please don’t hesitate to reach out if you have any other questions or concerns!
