Configuration Management - Config Transform vs Scoped Variables

Legacy Uncategorised
1

Hi,

I’m wondering what is considered best practice for environment specific config tranforms in Octopus. I’m currently going down the path of using variables that are scoped to environments, but finding two issues here:

  1. The number of variables across multiple environments is pretty big
  2. For things outside of AppSettings & ConnectionStrings, I need custom step template or a custom script, which I have in place

I feel that the route of File Config Transform would make maintenance easier, though wanted to get your thoughts on what you’ve seen work best for majority cases. I also saw this hybrid approach that is appealing:

Please advise.

Thanks!
Jafar

2

We use a combination of both. Our projects define a single configuration transform file (we name it Octopus.config) that performs all of our config transforms using Octopus variables. We then set each package deployment to “Substitute Variables in Files” on Octopus.config, then we apply a custom transformation of “Octopus.Config => Web.config” (or the .exe.config as the case may be). We also turn off the other options to substitute appSettings and values in config files since we’ve accounted for all of that explicitly within Octopus.config.

It doesn’t help a lot with the number of variables; for even a moderate number of environments, a handful of variables doesn’t take long to become a big list when you multiply it by the number of environments.

3

Gotcha, appreciate the quick feedback; I’ll give that approach a try. Thanks!

4

One other followup question… outside of the out-of-the-box config transform feature, do you have any feature that replaces an entire config file with another file in my project/solution? For example, if I have a file called “web.QA.config” (a copy of my main web.config), can I swap that file in at deploy time using Octopus?

5

Hi Jafar,

Thanks for reaching out! I completely agree with Adam’s approach of first replacing variables in the transform file, and then using it to transform the web.config.

outside of the out-of-the-box config transform feature, do you have any feature that replaces an entire config file with another file in my project/solution? For example, if I have a file called “web.QA.config” (a copy of my main web.config), can I swap that file in at deploy time using Octopus?

There’s no such feature. But it sounds like all you want to do is rename a file, which you could do using a script inside of the package step and then Rename-item.

Or you could always just add an xdt:replace to the root node of web.qa.config and use it to transform web.config.

Let me know if any of those approaches make sense for your scenario :slight_smile:

Thanks!
Dalmiro

6

Yup, both of those approaches sound good in terms of replacing the file outright.

I think for now I’m going to stick with the traditional config transform route, and will use variables for sensitive values.

Many thanks again for your guidance here!