State specific transforms?

We are working on building a custom component that will be deployed to various state law enforcement agencies that have partnered with us. This component is a middleware and will have different settings depending on the state (Louisiana, Texas, etc…). We want to use application config files similar to app.config. Where it may be named something like the following

CustomComponent.config (debug)
CustomComponent.LA.config (LA)
CustomComponent.TX.config (TX)

The problem is that Octopus / Teamcity have no notion of a State. They only know about Config Environments (Nightly, Staging, Beta, Production, etc…). How do I introduce the idea of a State specific configuration into my deployment procedure? Has anyone run into this?

We are at the very early stages, and are open to anything. The only reason we are going with app.config “type” settings system is because .NET has built in mechanisms for reading config files and getting key/values out, and Octopus supports transforming easily. Any ideas are welcome.

Hi Josh,

Thanks for getting in touch. This is definitely possible. The best way to accomplish this is by specifying your config transforms in the Additional transforms field to apply using a convention and a variable. In your scenario, it would look like this:


where #{RegionVariable} is a variable using scoping appropriate for you project/environment. You could scope it to anything that makes sense for your project. The most common ones would be environments or roles. I don’t know if you’re using multi-tenant deployments but if you were you could also explore using tenant tags for this purpose as well.

You can read a bit more about how we handle configuration transforms at the following URL. There’s also a child page w/ advanced config transform examples/scenarios as well.

The other big option is to move to using Octopus’ native variable substitution and centralise all your variables and scoping in Octopus itself.

Let me know how you go.



Interesting - now that you mention it - it may even just be easier and cleaner to use the app.config, and create machine-specific scopings. That way ComponentServer-TX machine will have TX values automatically populated. They will all point to the same DB, so Role scoped values would work there. No special Configuration loading, no config file per state - we can just use ConfigurationManager.AppSettings.

Sometimes I forget how flexible Octopus is.

Unfortunately we are on an old version (1-2 years old), but I think this could work.

Hi Josh,

Thanks for the reply. Yes, I think this should work. Even if you’re using an older version as the core variable substitution was done years ago. I always liked config transforms because they could live in source control and supported diffs etc but I think it’s simpler to manage variables with Octopus and use standard configuration variable substitution. Both approaches should work though.

Hope this helps!