At the moment my company deploys en mass roughly 100 micro services. For each micro service we have a manual interruption step. I created a tool which:
scheduled all deployments of the newest version
when ready accept all manual interventions from step 1
I have decided the new ‘Deploy Release step’ with OctopusBypassDeploymentMutex set to true would achieve step one. However can not achieve step 2 or at least figure a way to achieve similar behaviour.
Technically I could:
Create a master project, ‘Deploy All’
Set a global variable to turn off manual interruptions in all projects
use the deploy package step for each 100 project
Have a manual interruption step (not affected by the global variable)
have a ‘deploy release step’ for each of the 100 projects in parallel (10 at a time default)
the above approach would avoid me having to manually intervene in each of the 100 projects, and the downtime will be minimum as well as the packages will already be on the deployment targets. However it would mean I would have to extract all the post deploy scripts and either create a custom step to do the post deploy scripts etc.
Has anyone else encountered this scenario and what would you suggest, my current concept would require large rework and duplication of effort by having deploy packages steps twice, as each project will still need to be able to be independently deployed.
Thanks for getting in touch! You might want use variable based run condition for your manual intervention step and then skip it by supplying the right variable to the “Deploy a release” step.
thank you for the reply. If I were to turn off the manual interruption step (based on any variable) for all projects this would mean that the acquiring packing step would occur during our system downtime which were are limited to a small window of. (stage package upload)
Another approach I have thought of is this (steps 1 - 4 are all in parallel):
Deploy project A
Deploy project b
Deploy project …
manual interruption step ( warn users to only accept when projects a-z have interruption steps)
custom script which finds all projects in current master project, accept them (probably in groups of 5
however again this approach does not feel clean and instead feels quite dirty…
Is there not a way to acquire all the packages for the dependent projects? And if not is there not a way to accept them all in bulk?
I see now what you are trying to achieve. Unfortunately, “Deploy a release” step has a few limitations and the solution you’ve come up with looks good to me. Maybe a crazy idea, but if you always deploy all projects together then maybe it makes sense to merge them into one deployment process?
Yes that’s a good idea, however, we do need the ability to deploy each project separately for bug fixes, also there are some very specific configurations around which machine each project gets load balanced on etc (we actually deploy all our services to each server so technically we could run off one server if the other 9 went down. Not my design…).
Might implement it though for small groups of 10 though as some are quite tightly coupled
I might suggest the acquire all packages for dependencies in the octopus suggestion forum