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.
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
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.
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.
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.
Would this solve your problem?
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?
Any updates on this? While the new 4.X UI is nice, this RFC is 6 months old and would be incredibly useful.
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.
+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:
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
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:
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).
Tjeerd-menno Douma commented
The new step templates are a very big step in the right direction. But since it's limited to only 1 step per template it's usefulness is also limited.
I believe it would be very useful to be able to compose templates from multiple steps or add multiple child steps.
This would help template out common flow mechanisms and it helps making thing more DRY.