Configuration Management strategy?

I was just wondering if someone from Octopus could give their thoughts on how they are thinking about configuration management going forward. As our deployments get more complicated and involved, and as Octopus is adding features like multi-tenancy, management of the different variables is getting unwieldy. Add to this our use of config transforms, and the picture gets even more confusing. While we love Octopus, it seems that configuration management is one of the major missing pieces from the software (either intentionally or not). Are there any plans to tackle this area inside the Octopus software?

Just to clarify, I am thinking along the lines of things like:
Configuration Versioning (checkins, who changed what why, etc.)
Easier management of variables (scoping is currently a nightmare with somewhat complicated environments)
Recommendation on whether to store configs in source control and pass them to Octopus, or store them in Octopus directly

Please let me know what you guys are thinking about along these lines, or if it’s completely missing from your radar. Thanks!

Hi Ryan,

Thanks for reaching out!

At this point, our story around this area is not great, and personally I’d love to see it improved. At this point however, its not on our radar.

Based on what is in Octopus as of now, the best I can offer is to take a look at the audit log for the versioning history. For easier management of variables, there are some improvements in 3.4 (which we are hoping to release soon) but wont really address the scoping side of things.

Regarding source control of configuration, you may want to check out (blog post which allows you to define configuration as yaml and import / export from Octopus, in a similar fashion to the Jenkins Job Builder (if you know it).

Our main source of getting user feedback prioritisation is UserVoice. I’ve created a suggestion for this at Please vote and add your thoughts.

Hope this helps.