Micheal Schexnayder
My feedback
-
21 votesMicheal Schexnayder
supported this idea
·
-
1 voteMicheal Schexnayder
shared this idea
·
-
568 votes
Thanks everyone who voted on this. We’ve spent a lot of time thinking about how best to version control Octopus configuration, and came to an approach that is a little different to what was imagined in this blog post. I just published an RFC post with our plans – I’d really appreciate if you could take a look and leave a comment!
Micheal Schexnayder
supported this idea
·
An error occurred while saving the comment -
121 votes
An error occurred while saving the comment Micheal Schexnayder
commented
This would be very very helpful in helping us distinguish between multiple instances of OD.
Please implement!
Micheal Schexnayder
supported this idea
·
Along these lines, I think the needed functionality is being able to select the version of a step template to use as a part of a deployment process. This becomes important when you have many jobs using a step template and rollout of the changes can't be a "one-and-done" approach.
This idea has really forced us to re-evaluate how modifications to step templates occur on our systems; not just from a development standpoint but an impact to our customers standpoint. Essentially we've moved to a model where we artificially version the step templates with a version embedded in the name:
- My Template (v1.0)
- My Template (v1.1)
In this model step templates become immutable (except to fix bugs). New features are added as a new version of the template, there by not disturbing those who are using the older versions but making the new one available to those who want/need to use it.