Rolling using Deploy Release Step

Deploy package greatly suports Rolling Deploys achieving zero downtime…

We use bunch of Deploy Release steps for deploying different packages and i see Deploy Release step cant support for Rolling Deployment mechanism.

We are using version: 2019.10.0

I found some related posts on internet having discussions from past 2 years… Any idea if its already implemented in any newer version or any insights/other ways of achieving rolling via deploy release step is helpful. Please let me know . Thanks

@snamilla support for Deploy A Release within a Rolling Deployment was released in 2019.7.6

The thread you included shows that. It should be functional in the release that you are running.

@tfbryan: Thanks for responding as i was waiting to hear from you…

we are now in version 2019.11.3 upgraded

I dont think its true , Deploy a release step doesn’t have rolling configuration at all. I hope you are not confused between Deploy a release step Vs deploy package step.

I’m not confused, I submitted the original feature request. If you can add the Deploy a Release step within your rolling group of steps than it’s working. There is no specific configuration for it. Have you tried it? @snamilla

I am pretty sure i tried with our previous octopus version of 2019.10.0 and here is what i experienced during that time.

Lets say Parent Project called A and child project as B getting deployed using deploy a release step which gets deployed to servers count of 6 so we divide the rolling into 3 boxes at a time.

When Parent Project A is triggered which has rolling configured it triggered project B ( child) with first 3 machines but couldnt go to next 3 machines saying a note Project B got already deployed to xyz env… so basically machine context was not captured during parent project rolling so second half 3 boxes are never got deployed.

i dont know if above makes sense but that was my experience

@snamilla So it could be something with your configuration, or you’ve stumbled onto an edge case that isn’t supported. I use the feature now with single host rolling execution and it seems to be fine. Are both your parent and child projects set up for Rolling deployment? That’s how I have it set up and it works.

yes both parent and child configured for rolling… let me try some more pieces looked and reach you thanks.

HI Todd,

Whats the best way to connect with you to go over on our process

Hi @snamilla

Would you be able to export your deployment process and send it through in an email to (att Alex) so that we can investigate this further for you.

If you can also let me know which version of Octopus you are currently running that would be greatly appreciated.


HI Alex,

We are using octopus 2019.11.3 version…

so i found the article below under Rolling Deployment section stating exact problem i am facing…

Does the Deployment Condition should always be set as “Deploy Always” in deploy release step? if thats the case then its difficult for us since we have bunch of deploy release steps and not all gets modified in every release but because of Deploy Always condition it gets deployed everytime without changes.

HI @snamilla

Does the Deployment Condition should always be set as “Deploy Always” in deploy release step?

That’s correct, otherwise we won’t deploy correctly as we see that the release has already been deployed to that environment and skip the deployment to the remaining targets in that environment.

It might be worth gettting in touch with out customer success team ( as they can spend some time working with you on your deployment process and may be able to assist with a workaround.

Sorry that I wasn’t able to help here.


Now that I have tried using the Deployment Conditions to skip, I’m having the same struggle. Why are there Deployment conditions if they don’t work unless you only deploy to a single target?

I have a huge orchestration project that calls dozens of other projects through Deploy a Release steps. Some of these are grouped into Rolling steps and others are grouped and set to Parallel execution. In both cases, none of the deployments worked as expected when the Deploy a Release steps were set to Skip unless selected version is higher. In a multi-server environment, most servers were skipped once one server was successfully deployed. If I set the Deploy a Release steps to Always Deploy, and I rely on the child projects to skip, then I am left in a situation where a bunch of non-package deployment steps run no matter what, even if the package deployment step itself gets skipped. This is far from ideal. Now I’m left thinking that my only option is to trust the users to selectively exclude all projects that should not be deployed during that particular release. This is also far from ideal as humans make mistakes.

Hi Todd,

Thanks for describing your scenario so succinctly.

I definitely agree with the premise that humans make mistakes. I have passed this information through to our product team who I know where investigating improvements in this area at one point recently.

Hopefully this will be something that we can get sorted for you, in the meantime it would be good if you could raise this over our on uservoice so that it has extra visibility.


1 Like