Without getting too much into the weeds of the stack and why it’s necessary, I have a need for a rolling deployment to target 1 server on the first pass then increase to more after that first pass succeeds.
Currently I can either hardcode a value in the rolling deployment window size or use a variable. Either way, that is just a constant value.
Can the variable be updated at the end of the first pass somehow (and would that even matter since the process is past the point where it originally referenced it)?
Can the window size be a condition that says something like … if this is the first pass, use 1 otherwise, use 5? I know I can use conditions inside of #{} but I do not know how to get the current rolling iteration. And, again, even if I did put a condition n the “Window Size” setting, would it be evaluated each pass or only the first time?
Hey @bhartsfield , thanks for reaching out and welcome to the forum!
Unfortunately, I’m not very good at avoiding “getting too much into the weeds of the stack and why it’s necessary”
Generally speaking, there’s not a great native way to modify window size in between deployment runs. However, there are other ways to model what you’re looking for - the process you’re describing (deploy one, confirm health, deploy more) is very close to sounding like canary deployments.
If canary would work for your scenario, we have some examples of how it can be implemented using Octopus -
Sample deployment process - Pattern - Canary (log in as a guest!)
Have a look at those, and let me know if that helps you with how you want to design your process. If you have any additional questions or concerns, feel free to ask away - we’re happy to help as you get your process aligned and configured!
