Composite Step Templates RFC
Composite Step Templates and the related proposal, Inheritable Templates, are two UserVoice suggestions that we are planning on addressing in the coming few months. We want to hear from our users to make sure we are solving your problems in the right way. Throughout this RFC we have highlighted with bold some of the questions that we are still considering (which have involved much debating internally) that we would love to hear your thoughts about, especially within the context of your deployments and the problems you face.
What is it?
It is often the case that you will have several steps that need to be included together in multiple projects. Whilst it is easy enough to turn a single step into a shareable step template, dealing with multiple steps in a single unified way typically requires a higher maintenance costs. Perhaps you want to reuse a set of deployment steps throughout your projects that should all get updated when a new package deployment step needs to be added. That is where composite step templates will come into play. By effectively bundling up multiple steps into a single, reusable step that can be included in your projects (or other composite step templates!), you can reduce duplicate configuration through your system and ensure that changes across projects are kept in sync.
Our current plans involve creating and treating composite step templates just like a typical step template with a few key differences. The inner details of the template consist of other steps, which can be either custom steps, other step templates or even other composite step templates!
When added to a project, the composite step template is treated like a single block of steps. Is there any reason the single step-block concept would not work for you? Would you prefer to be able to run project level steps in between composite template steps? Target roles for the inner steps are inherited from the project-level role configuration on the project step edit screen. Does setting the roles on the project level make sense or will it cause problems that outweigh the complexities of setting them individually? Any parameters that you wish to expose on the project level need to be explicitly configured on the composite-level, otherwise the values explicitly provided in the composite-level configuration will be used. Do you think that you would want to expose the inner step parameters on the project level?
What this is not
These are not fully fledged project templates, though you might get a good part of the way there by templating out all the shared steps needed for your deployment. Shared variables would be best handled by creating a shared library variable set, something that exists already. Channels would still currently need to be managed on a project-by-project basis. Some of the commenters in UserVoice saw this solution framed in a similar light to TeamCity build templates. Given the different context that deployments bring, we don't see this as necessarily the same concept.
The composite step templates feature is not intended to provide security or business compliance to your deployments. They are included into your deployment process in the order they are configured, without the ability to rearrange the steps or intersperse your project steps between them. If you want to ensure that something like an email step is executed at the start or end of every deployment then we would recommend writing custom scripts to periodically inspect your deployments for the all the variations that you may need in your business. The composite step template is about code reuse and simplified management of shared deployment configurations.
Although UserVoice comments suggested the ability to automatically update all projects that use the template when it is updated, we feel that with a better solution just around the corner that will solve the problem of updating, updates will soon be better solved through a simpler manual upgrade process.
We currently don't consider exporting composite step templates to be in scope for the first version of this feature. Exporting a composite step template raises several problematic questions. If you export a composite step template made up of other step templates, how would that linkage be expected to be preserved if imported again? It seems as though you would need to import the inner steps as new independent templates. Would exporting provide much value at all over and above the existing step template exports?
Questions
Hopefully you can see some of the benefits that this feature will bring in simplifying your deployment configurations. As you can tell we do still have a few open questions that we are considering and could use your input. Does it make sense to treat the composite template as a single step or do you see a need for allowing it to be managed on the project level as seperate steps? How should parameters of inner steps be exposed on the project level, if at all? Let us know what what you think we are missing and be sure to describe some of specific problems that this would or wouldn't solve so that we can better shape it going forward.
