I’m looking to see how close I can get to this scenario. When I create a full release (1.0.0) for my project it will deploy:
Step 1: Service X
Step 2: Service Y
Step 3: Service Z
However when I want to deploy a patch release (1.1.0) I wouldn’t deploy every service since they haven’t all changed. I want to be able to define at a release/version level what deployment steps to exclude so that when I deploy my patch release I don’t need to specifically exclude steps each time. This would be important for consistency between testing and production to make sure the code that was tested is the same code that we release.
Additionally this would also be a nice extension to the “Deploy A Release” step type so that if I had a coordinator project that could release a specific version of each project I could define, in my coordinator project, version 1.1.0 which deployed Project A (exclude step 2) and no other projects as it passes through each environment.
Has this requirement ever come up before, I can think of a lot of hacky ways to solve this but none that deliver a solid user experience (or that would be fun to debug/maintain).
Thank you for reaching out to us with your query about excluding deployment steps.
One possibility might be to use a variable expression as a Run Condition on the relevant steps. This could check the value of a particular variable (e.g. “skipServiceY”) and run or skip the step as appropriate. You would set the variables as needed just before creating a release and they would remain consistent between environments.
Would this be a good option for your requirements?
Thanks for getting back to me. Unfortunately in one of my projects I have over 100 steps deploying micro-services and so creating and managing variables for all of these would be very tedious. That was one of my potential solutions and honestly probably the best I could come up with for this particular issue.
I’ve looked into this with the team and it seems that something similar to this approach is likely to be the best solution at the moment. You can read a great overview and see a worked example in the article linked below.
I hope this is helpful. Please let me know if you have any questions.
That’s a really interesting read, I haven’t made use of run conditions really anywhere in our setup. I’m afraid our current process of excluding steps on deployment is still the easiest/most straightforward solution. I would say these are the key things I was looking for:
The ability to exclude steps once per release
– Would not need to be changed on deployment
– The solution involving creating variables to skip steps then creating the release is probably as close as I can get here
The steps that are excluded can change per release
– There is no restriction on this, I could deploy Services A-H one release and Services B,V,Y in another
I don’t think with the tools currently available I can implement a solution that is more appropriate to our needs than what is currently in place. Thank you for the help and the interesting reading, it’s always good to learn more about a tool we use very heavily.
Actually I just had an amazing idea that makes use of something in that post and covers the two key points that I mentioned above. Currently I have a project with 100 steps (each step just uses a step template to deploy a service, each service deploys a unique package) and I have to exclude the steps that I don’t want to run. But what if instead I set the version number to 0.0.0 of the packages of the services I didn’t want to deploy and added a conditional run check on each step. So if the package version designated by the release is 0 then this step shouldn’t run.
Since each service has a unique package and all the names match up that would exclude that step(service) from every deployment of that release. I could even integrate it into our build/deploy pipeline so that Teamcity only builds the required services and pushes them with the correct version number to Octopus while setting the version of all unneeded packages to 0.0.0 when it creates the release in Octopus.
This wouldn’t work for steps without a package assigned but that isn’t currently a problem.
Thanks for your message and for sharing your thoughts.
It sounds like you may have a workable solution there so it could be worth trying. You might also want to consider using a combination of the run conditions approach discussed above with a master project to orchestrate them as another alternative.
There’s a few possible options here so hopefully one will be a good match for your requirements. Please let me know what you decide to go with and how it works out!