Allow finer control over config transforms

[peter-dolkens]

When trying to keep projects compatible with multiple different processes / systems, sometimes it's necessary to keep some transforms around that you don't necessarily want run by convention on deploy.

It would be great if there was an option, when turning on config transforms, to disable the convention options, and only run an explicit transform (I believe the explicit transform is possible, but the convention part is not)

[PaulStovell]

What if we created a special syntax that looked like this:

Web.Release.config => Web.config
Web.#{Octopus.Environment.Name}.config => Web.config
*.Foo.config => *.Bar.config

Which means:

1. Run the Web.Release.config transform over Web.config
2. Run the Web.<environment>.config transform over Web.config
3. For any XYZ.Bar.config file, find a matching XYZ.Foo.config file

Then you could edit this specification, add/remove the transforms you want, and change the order that they run in.

This setting could also be bound to a variable, so different transforms could be run for different environments.

[peter-dolkens]

Very team-city - I like it.

The other edge case (which is where I found this initially) is that upper/lowercase names should be de-duped, even if doing it this way with variables.

In our environment, I had an environment called "release", and it was running the transform "web.Release.config" then "web.release.config" and failing the second time due to the transforms performed. Probably should have recognised both as being identical.

[nblumhardt]

Popped into the 2.1 bucket, since we'd like to address this soon but won't hold up 2.0 for it.

Just a thought, and maybe a workaround for the short term - it might be possible to invoke transforms through PowerShell in Deploy.ps1?

[peter-dolkens]

For my use case, I just renamed our environment from "release" to "release.deepend.local" - sorted it right out for now, and I agree, not something worth holding up the main release of 2.0 for.

[nblumhardt]

Moving to the backlog to consider in the next cut, doesn't fit our current goals for 2.2.

[Tazer]

+1 to be able to handle the convention how octopus finds the config to use for transform.

Cause our problem is that we have like web.test.config and web.test.en.confg and web.test.no.config (depending in language) , It's hosted as seperated site but uses same codebase except for web.configs.

So our convention would be something like Web.#{Octopus.Environment.Name}.#{Site.Language}.config

[dstrickland67]

Here is something to consider when thinking about this. We use NServiceBus for computing cluster. The XML Config for all those xml elements are like <msmqSettings>.... <unicastSettings> ....
I like the idea of embedding those special values in octopus and have them replace them, but 90 percent of the values that we need changed are not in the appSetting nodes, but are at the same level as the appSetting node. I am not a huge fan of the transforms because today we have a single shared T4 transform that generate these files thru an include and thus they are essentially the same, but a transform sounds like that we would need to essentially maintain about 100 file that are nearly clones of each other. If you could use the xpath and the specify the value for each environment/ machine, that might be handier.

[dave-sansum]

Just a couple of suggestions which would solve some of the customization we've made ourselves around this area.

1. Don't just restrict to just .config files. For example we use XDT transforms for crossdomainpolicy.xml files.

2. Allow the transforms to be stored as part of the package or as text fields in the UI. Personally this would be a big win as we scale and change our environments frequently and this allows us to de-couple development/source code from deployment/environments so we don't have to re-build the nuget package just for a config change.

[plukevdh]

I'm a little confused on this proposal: Would this convention allow for the running of a Web.QA.config in the event that I wanted to share a config between environments named Web.QA1.config and Web.QA2.config? This is an enhancement I would like to see happen as multiple similar but unique environments that would benefit from shared transforms is a frequent case for me.

[PaulStovell]

@plukevdh yes, you'd just define a variable called 'SharedConfigName' with a value of 'QA' scoped to QA1 and QA2. Then define the transform as:

Web.<SharedConfigName>.config => Web.config

[PaulStovell]

Merged Jeff's implementation into 2.5 - great one @jeff-french!

[crossetj]

@PaulStovell Will this allow us to define a common transform that is run in a subset of environments?

For example, for one project the testing / production transforms look similar but the development one is quite different so we can't use web.release.config

I'd like to be able to run Web.#{Octopus.Environment.Name}.config => Web.config in all environments and Web.Common.config => Web.Config outside of Development.

If this implementation gracefully skips undefined transformation files I could do something like:

Web.#{Octopus.Environment.Name}.config => Web.config
Web.#{SharedConfigName}.config => Web.config

And leave #{SharedConfigName} undefined for environments I don't want it to run in.

[PaulStovell]

@crossetj that's exactly how it will work.

[MattLaw75]

Hi Paul

I have a similar, but different need from Octopus.

Let's say (because I do) have multiple test environments. Systest-01..Systest-50 (big org).
And I want all these environments to share a single config file. i.e. web.systest.config

I'd like to be able to get octopus to use the Systest part and ignore the number index.

Is this possible?

Matt

[jeff-french]

@MattLaw75 So you want the web.systest.config to be applied in all Systest-* environments but not in other environments, right?

Try this:

• Define a variable called SystestConfigFile with the value set to web.systest.config => web.config
• Scope that variable to the systest environments
• In the Additional Transforms box add that variable: #{SystestConfigFile}

Now when Octopus processes the additional config transforms for that deployment step the web.systest.config transforms will be applied to web.config only when deploying to a Systest-* environment.

[MattLaw75]

Beautifully simple - sorry I didn't think of it myself, still learning :)

[jeff-french]

No problem. Glad I could help. :)

[andreas-runnhagen]

@PaulStovell It would be great if this would be added to the documentation at http://docs.octopusdeploy.com/display/OD/Configuration+files with some examples of expressions you can use.

This page was the only reference i could find regarding this type of configuration.

It would also be great with some better Task logging when you resolve "Additional transforms". If a path is misspelled or something it is just silently skipped. A bit of Info/Verbose logging to give a hint that a path has been skipped would be great.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you think you've found a related issue, please contact our support team so we can triage your issue, and make sure it's handled appropriately.