Thanks for getting in touch! That will work out of the box with variables. You will just need to define the three variables and their values and it will do the transformations.
Make sure to choose the feature in the package step. “Configuration Variables” is the feature you want.
How does it know which portion of the configuration to change?
Taking a specific item
For example. I’ve tried this now as you suggested and it did update the connectionString portion which is great. But how does it know to update the value of the connectionString vs. providerName? Not that in this case I want providerName updated, but if I did how would I do it? I feel like I’m missing something obvious.
Or if another example is helpful how would I refer to the initializeData portion of the “logName” under sharedListeners so I could control where the log is being written out (without touching the key under sources.source name.logname?
I think Vanessa is suggesting that you define specific placeholders in your config file like #{MyVariableName}, which Octopus will then replace. We do this for everything even though Octopus does “intelligent replacement” in cscfg files, for example (I actually don’t like the auto-magic replacement behavior because it can be confusing as you’ve suggested).
We specifically only change “ConnectionStrings” or anything inside “AppSettings” everything else will not be substituted unless you use the “Substitute variables in files” feature and specifically define a variable to replace.
So in your example below, if you want to replace where a log is outputted you would need to create a variable such as initializeDataLogPath and then define your config file name under “Substitute varaibles in files” and actually place the variable #{initializeDataLogPath} where you want this path replaced.
(Please see attached screenshots)
I hope this helps explain it a bit better!
Vanessa
Makes perfect sense. I just don’t know that I’ve seen what you say below about only app settings and then connection string actually documented anywhere, so I wasn’t sure if there was a syntax I was missing. I did know about know about the key/value pairs, and although I didn’t say it, I did know about the defined variable substitutions. And variables are where I have been poking around because the projects I’m working on swapping over from our homemade solution have developers who have their heads down and aren’t at a point where they can offer a lot of help swapping in and out web.config values and I don’t want to be in a mixed environment when it comes time for them to deploy.
The two other specific places I had been curious with variables and about was the logging, and switching it from “Error” to “All” and then back again. I can write something, but had been wondering that was something out of the box.
Additionally (and I put this in UserVoice and it probably should have been a question), I was trying to figure out whether there was a way to scope variables so they couldn’t be used in variable substitution in files. So if I have a step template that I’ve created (or have imported from the Octopus Step Template Library) that has a variable defined, I don’t want to find that some developer called a setting in the config that and have it changed.
Variables for logging, I’ve seen many instances where customers will define the error and all depending on environment.
And for step templates and variables. If you are referring to the variables created and used in the step templates, these are by default confined to their own step. If you are otherwise referring to a project variable that is also used in a step template, to stop it from being used elsewhere you could scope it specifically to that step, and if it’s then created by devs, your step set variable would not be available.
