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!
An error occurred while saving the commentClayton commented
It worth noting that you can achieve this outcome without Octopus features. The deployment logic really should be scripted and controlled directly with the application, it should not be separated at all, evolving in lock step with it on the same branches. We do this, and have only ever used Octopus as a layer over the top, that calls those native installers we include in our apps, and allowing additional orchestration to handle multi server environments. This installation logic is a deliverable from the dev team, and testable by them, before Octopus enters the picture.
13 votesClayton shared this idea ·