Is it possible to deploy to different target roles in child steps within a rolling deployment in Octopus Deploy?

I’m new to Octopus and I have been tasked with making our existing websites be deployed with zero downtime. I have two websites and each is hosted on the same 3 servers.

I saw that Octopus supports rolling deployments, and I can see that you can configure a rolling deployment to “run on target roles”.

My question is - is it possible to select different roles to be used in each child step as part of a rolling deployment?

I’d like the rolling deployment to look like this:

Window Size = 1

  • Remove Server from Load Balancer
  • Deploy Website 1 with the role of website-role1
  • Deploy Website 2 with the role of website-role2
  • Add Server from Load Balancer

Unfortunately there isn’t currently an option in Octopus to run child steps on target roles that differ from the ones applied to the parent step.

When you configure a rolling deployment in Octopus, it is possible to select multiple target roles but the roles chosen will apply to all of the child steps in the rolling deployment.

This is also true for the Window Size selected by the parent step too.

Split out each deployment into separate rolling deployments

One alternative to the desired solution would be to split out each of the website deployments into their own set of child steps.

  • Website1 would have one set of child-steps set as a rolling deployment using target role website1
  • Website2 would have one set of child-steps set as a rolling deployment using target role website2.

In that scenario, the deployment process would look like this:

You could run both parent steps in parallel if you wanted to kick off deployments to both websites at the same time by adjusting the Start Trigger for the Deploy Website2 step to Run in parallel with the previous step:

Are there plans to improve this feature of Octopus?

As can be seen in the example on this post, repetition is often required for the simplest of tasks due to limitations of this feature. It makes maintaining the projects more difficult and adds additional risk by necessitating updates in multiple places.

What would be better IMO is to allow for arbitrary groups where each step can still define it’s own set of roles (if any are required), allowing groupings for convenience where a single role for all steps is not appropriate.

As an example, a deployment that creates an EKS cluster on AWS requires three steps. Step three requires a role, but steps 1 and 2 do not, and even allowing for deployments to run where there are no targets, the deployment fails on step 2 because it tries to connect to the deployment target that it is about to create (and which is required by step 3). This means that I can’t group steps together, and it just makes things untidy and harder to follow.

  1. Create the EKS cluster.
  2. Create an Octopus deployment target.
  3. Add a config map to the EKS cluster.

I can’t find any UserVoice on this, but I’m hoping it’s something that is on the cards.

Hi @dgard1981

Thanks for your question.

This topic comes up quite a bit, and has been discussed recently. I’ve raised it again internally again for visibility. The idea of being able to group child steps together for better organization and also being able to set common things like run conditions, scopes, etc on the parent step once to remove repetition would be a very nice addition to Octopus.

I want to be transparent and say whilst there is definitely an appetite to look at improvements to this area in the future, it’s not currently part of any planned work right now.

In the meantime, I’d encourage you to add the idea to UserVoice. I also couldn’t find a specific match to your suggestion.

I hope that helps

Best,

Hi Mark,

Thanks for you reply.

Grouping for organisation is really what I’m after. I like the idea of being able to set run conditions from the parent, but would suggest that the can be overridden in the child step if desired. So when a child step is moved into a parent step, each of the run conditions could default to ‘inherit from parent’ rather than the usual default, and of course any conditions that have already been added should be retained.

UserVoice is great in principal, but because users are only allocated a certain number of votes it means that ideas around topics like this can’t be added. So in this case, because some other ideas already on there are worthy of a vote, it means that I can’t raise this :frowning_face:

Hey @dgard1981

Sorry about that, I’ve added the idea on your behalf here:

1 Like