We have installed 2.6, and it was my understanding that steps could now be run in parallel. I didn’t realize, however, that this excluded child steps? I can set the trigger to run in parallel on a top level step, but its child steps cannot be run in parallel? Doesn’t that somewhat defeat the purpose of using Child Steps at all?
Thanks for getting in touch! You have a good point there. Child steps are used mostly as a way to group steps that take part of a same sub process like “deploy a web app” or “Deploy a service” that need to run in a specific order as a mandatory condition. Let me give you a quick example of how to use these 2 features together on a deployment process:
In this case you would like to run DeployWebApp and DeployService in parallel, as they are separate sub processes that don’t step on each other and could easily run at the same time. The child steps on the other hand, you wouldn’t want those to run in parallel with their siblings.
Would you like to share us your current deployment process to see how you’re trying to implement child and parallel steps?
I see. We are using the child steps feature as more of a logical grouping than a functional grouping. In our case, two main tasks: Rollout Websites and Rollout Services, with multiple child steps under that. I suppose we could break them up and use them as you prescribe, but it would be nice to have the option.
I have read up on this a bit more, and still think that this needs a fix. According to the documentation:
“Rolling deployments allow you to wait for a step to finish on one machine before starting the step on the next machine. But what if you need to perform a series of steps on one machine, before starting that series of steps on the next machine? To support this, Octopus allows you to create Child Steps.”
In fact, we are using a rolling deployment to ensure uptime, and without being able to run Child Steps in parallel, there is no way to do a combination of parallel steps and rolling deployment. This seems to be an oversight, and in our case, a big opportunity for speedup in the rollout process.
I’ve had a bit of a discussion about this and it wasn’t an oversight, but was not implemented due to complexity. Unfortunately it is a complex issue that has too many variations of possible expected behavior that we do not think a suitable solution could be provided that would work for ‘enough’ people in the ‘correct’ way.
I think the best step forward would be a UserVoice suggestion to see how many customers require this function, and their comments about how it should behave.
Please put your feedback in the suggestion about how you think it should work in your case.
I’m not quite sure the explanation and example you gave it really all that clear.
As per @lonevvolf, “Rolling deployments allow you to wait for a step to finish on one machine before starting the step on the next machine. But what if you need to perform a series of steps on one machine, before starting that series of steps on the next machine? To support this, Octopus allows you to create Child Steps.” To me, this seems relatively clear in its meaning, however couple with the example:
–Stop IIS --Backup app --Deploy app --Start IIS
–Stop service --Deploy service --Start service
Vanessa is saying that webapp and service can be deployed in parallel across environments, but the child steps are one after the other in rolling. But even normally, without a child step, in that all steps run in parallel, they still are executed one after the other, i.e. Stop IIS, Backup app NEVER run on the same machine at the same time, they are in sequence??
I guess a follow up question, is if I just have a website, should I create all the steps as childs, or just leave them as normal?
Backup site, Put web offline, deploy files, Put web online, warmup site etc?
Thanks for reaching out. If you are only going to deploy one web site, it makes more sense to leave the steps as normal.