Thank you for reaching out to us with your query about separating configuration from deployment.
I’ve checked and the built-in steps that you mentioned aren’t able to be used for just configuration. You might however be able to modify the configuration using a custom script. The script would read the necessary variables from Octopus Deploy and make the changes directly.
We can’t create the script for you but I did find the following Stack Overflow discussion after a quick bit of searching which might be useful:
I hope this is helpful. Please let me know if you have any questions.
The thing is, I’m trying to configure some very clean projects, using only official Octopus steps.
But if the only way is to create some custom scripts, then so be it
I have to present my new configuration to my CTO and the devs tomorrow in a live demo, I’m trying to come prepared and I want to be able to answer all their questions.
I’m pretty sure they’re going to ask about a possible separation between deployment and configuration.
By the way, is there a way to configure a separate configuration pipeline for my projects?
E.g. A separate configuration project, that would find the appropriate path for the folders and .config files of my service projects.
My service projects are using tenant variables (‘Project templates’) extensively to configure some custom installation paths.
I’m still unsure if the configuration should be integrated within the deployment project itself.
Sure. We don’t want to restart that service too often for business reasons.
When we restart it, it kicks our customers out.
We only restart it using a special procedure to prevent anyone being disconnected.
That procedure is so convoluted we haven’t automated it (yet). (sadface)
In the end, the devs would like to have the option to update the configuration without deploying/restarting.
To support this, you could package your service and configuration files into separate packages. This would result in two distinct steps in your process, a Deploy a Windows Service step and a Deploy a Package step. The Deploy a Package step contains the same features and could perform the variable replacement/XML transforms you’re currently doing.