Add ability to run Child Steps in Parallel
With Octopus 2.6 you can now run steps in parallel, currently this is not extended to Child steps due to the complexity of the issue. If you would like to see this behavior built into Octopus please, vote! Also comment on how you think it should work:
Should you only be able to run them in parallel with other child steps, or would you expect a child step to be able to run in parallel with the above previous parent's step?
Would a parent step below a set of child steps run in parallel with a child step or with the parent step or with the previous parent's step.
We are really needing this. Otherwise we have to start looking at Jenkins and i really do not want to retool the entire damn pipeline. We have 100 steps and this one child step (with over 40 steps) is only so the servers can be deployed sequentially in two groups at a time. But we really want to speed this up by having all their steps run at once (or at least several at once). Would be awesome if it could mimic regular steps so our first that pulls the server out of the ALB runs, then the others all run when that step is completed. btw, its July 2019
Team Octopus - Will this be something you are looking at in the future? My current estimate is this could 1/2 the deployment time of some of our releases and would be amazing to see!
Otto Dandenell commented
Without this suggested feature, the logical grouping of child tasks means that a deployment of 20 coherent web services takes a loooot longer than needed.
Please prioritize this.
Paul Spain commented
I would very much like to see the ability to run child steps in parallel in exactly the same way as steps. Not having this means i have to move what would be a child step out into a normal step so that I can run it in parallel. This works fine but means my process has lost its level of reasonability meaning that i now have to disable many steps when really what i want to disable is VM deployment or some other significant step.
Josh Michielsen commented
Adding support for this. The documentation is not really clear on how child steps are handled. For example, this page:https://octopus.com/docs/patterns/rolling-deployments#Rollingdeployments-Childsteps, says "All child steps run on the same machine at the same time...". This seems to be incorrect.
I would like child steps to have the same option as other steps - either wait to start, or run in parallel.
Scott Brickey commented
I would like to see all child steps occur in parallel (setting in the parent step).
in my case, I've got a pre-deployment validation to check that databases are online (since we're full CI, and occasionally the databases are reloaded from PROD, or could potentially be down entirely)... I've got 4 child steps (one for each of the databases that the project uses)... they can all run in parallel, no risk.
of course, I assume that if ANY fails, the parent will fail, and the process will stop.
Michael Ferioli commented
We keep waiting for this feature to become available. Our particular use case is that we have steps that remove the current server from a web farm in our load balancer. There are two groups in the farm, one for HTTP and the other for HTTPS. We wait for all active connections to drain before proceeding with the deploy. This can take up to 15 minutes per group. Because these run consecutively, we can be waiting up to 30 minutes for a deploy to start on each machine. We'd really like these two steps to run in parallel so we drain both groups simultaneously.
The current implementation only allows one group of parallel steps at a time.
I would like to be able to group process steps for parallel/series execution and even just organisation of process steps. I could then choose to run multiple sequences at once, some containing parallelised sub tasks, others in series.
Jon Kennerly commented
I would add that Child Steps provide a wonderful "logical grouping", but should still retain the option of parallel or not within that grouping. It shouldn't just be considered a structural framework for rolling deployments (steps in series).
Ryan Adler commented
In this case, I would just give Child Steps a Start Trigger field, just like their parent's settings. The setting would allow child steps of a single top-level step to run in parallel with each other. Then, depending on the setting of the next top-level step, its children could also run in parallel with the first group of children.
For example for the following structure:
If Step 1.2 has a start trigger which lets it run in parallel, it would run at the same time as Step 1.1.
If Step 2 is set to wait for Step 1 to finish, it will wait until all the children are done.
If Step 2 is set to run in parallel with Step 1, then I would expect Step 2.1 to be able to run at the same time as Steps 1.1 and 1.2.
Likewise, if Step 2.2 is set to run in parallel, it could run at the same time as Steps 1.1 and 1.2.
If Step 2.2 is set to wait for the previous step to finish, it would wait for Step 2.1 to finish before running.
To summarize, the Child Step Trigger setting would affect whether or not children of the same step can run together, while the trigger setting on the parent would determine if the children could start in parallel of another top-level step.
Ryan Adler commented
Note that also, without this feature, it is not possible to take advantage of rolling deployments and parallel steps at the same time.