Composite Step Templates
There are sets of common steps that we very often want to "bookend" all of our deployments with. One concrete example would be: sending out a Manual Intervention to confirm when all servers are confirmed live before stamping a new deployment in NewRelic.
Right now, everyone has to bake these steps into their own projects by adding the Manual Intervention step followed by the NewRelic Deployment Stamp step. If it were possible to create what I would call "Composite Step Templates" then I could define a reusable step template that was made up of other step templates. That way, instead of everyone having to repeat all of the possible steps in their own projects, they would simply include this one composite step and they'd be done.
Now, my composite example was only two steps to keep it simple, but you can imagine maybe a composite is made up of more than that. Or even imagine a change in policy where the Manual Intervention email has to include more information. Everyone has to repeat this stuff in all their projects and having the ability to put it into a composite step would alleviate all of that.
Drew Marsh
shared this idea
We have begun implementation of this feature.
Thank-you for all the comments on the RFC: https://octopus.com/blog/rfc-composite-step-templates
You can see the rough spec here: https://github.com/OctopusDeploy/Specs/blob/master/CompositeStepTemplates/index.md
21 comments
-
Anonymous
commented
Really looking forward to this feature. It is a pretty big deal for us as we have a fair amount of projects.
-
Mark Derman
commented
Hi
Any word on when this feature is slated to be released please?
All our database automation follows a different multi-step review and approval process for PreProduction and Production and I am hesitant to roll this out across > 50 systems without encapsulating it in a multi-step template...
Thanks for a great platform.
-
Rob
commented
I hope development starts up again. We have templates in our current solution and are reluctant to give it up to enter deployment configuration maintenance nightmare.
-
Naime Islam
commented
Nice.Thank you.
-
Bruno
commented
I sorry that you have paused the most voted feature. It seems a feature so important in order to promote reusability of composite steps between projects, that when without it, it becomes very hard to manage when we need to introduce a change in the composition. Today we are using VSTS Release Mgmt and this feature is the only one missing from Octopus that is preventing is to start a real migration to Octopus. (VSTS provides the Task Group feature).
-
We have had to pause development of this feature while we focus on finishing work on spaces. We expect to get back to complete this work sometime in the next quarter.
-
Chris Camburn
commented
Any chance of an update? We have a few hundred projects, with only a few project types, and it's becoming cumbersome to manage even trying to script out the API changes to projects.
-
Bruno
commented
What is the ETA of this feature?
I am planning to do a big migration from VSTS Release Mgmt to Octopus Deploy because VSTS doesn't allow to reuse a "lifecycle" between different definitions. However VSTS supports to reuse a composite step template (Task Group), which is also important for us.
-
@ChrisCamburn we are looking at adding support to expose package selection on step templates out to the consuming project so that users no longer need to rely on variables to get different package values into a step template.
https://github.com/OctopusDeploy/Issues/issues/4270
Would this solve your problem? -
Chris Camburn
commented
One additional request: We use a number of standard settings for IIS, and the current built-in IIS deployment step is perfect, so that we don't have to script everything ourselves. We'd like to use that as a step template, so that any changes to how we deploy IIS sites can apply to all projects at once. Unfortunately, to do that we have to use a variable for the package name, which breaks the retention policy. Unlike most steps where we can reference a previous package step name, the IIS step requires the package be in the step.
Is it possible to have a new template parameter type for a Package Name, that still uses the autocomplete that most package deployment steps have? Or possibly a way to pass in the package name to a template while having Octopus retention policies run correctly?
-
Chris Camburn
commented
Any updates on this? While the new 4.X UI is nice, this RFC is 6 months old and would be incredibly useful.
-
Anonymous
commented
I agree, project templates are very important when working on a bunch of micro-services.
-
Darren Aitcheson
commented
+1 from me also.
What would also be useful here is to have the concept of non-skippable step (apart from the manual intervention steps of course).
Our scenario - we currently have steps that have to go at the beginning and end of all of our deployments for SOX compliance reasons. We want to give the devs access to modify their own processes, but these particular steps must always be there and mustn't be allowed to be skipped by the users.
Some way of making that happen would be great.
-
Chris Camburn
commented
+1 to the ability to have this function like TeamCity. It would be nice when you have multiple projects all based on a template to update in one place and have that change propagate.
-
Kenneth Truyers
commented
This is a duplicate from:
and
https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/6559846-inheritable-templates
FYI: These three items together would be the top-most requested feature (just saying :-) )
-
Kalvin Krueger
commented
Any updates on potentially including this feature. It has a lot of votes and would be really helpful in creating a deploy step, where I could also run powershell server setup afterwards, but when pulling it in I can package it in 1 step template instead of 3
-
Michael Freidgeim commented
See also similar (or duplicate?) suggestion https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/5923829-add-the-ability-to-add-child-steps-an-or-multiple
-
Andris
commented
I'm also missing something what would make easier to share common deployment processes across multiple projects.
I really like idea mentioned in this other suggestion, that it could be process template functionality similar to what TeamCity has:
https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/6072178-when-updating-a-step-template-update-across-all -
Jonas
commented
We often configures a website in a specific way, such as what should be logged and where, adding some writable folders etc.
This is done on all our sites and is, at the moment, done with one powershell script in one step template. Since this step i basically three steps it would be much nicer if I was able to have three childsteps. Easy to configure in the projects and easy to se whats done.
-
Kenneth Truyers
commented
I agree, a system like teamcity where you have build templates (that'd be deploy templates) and metarunners (step templates) would be great. Step templates is a very nice feature, but one more level would be really handy
We currently have 10+ different but standardized projects that share the exact same steps, so every time our process changes we have to make the change on all projects. When we add a new project we have to add them manually (or clone an existing projecr).