Hi,
Currently our Octopus Server is configured so that we can deploy our client application to different environments (Dev, UAT, Staging, etc). Any client deployment end up on a Tentacle on the tester’s machine, and produce the same output binaries.
The only difference when deploying to one environment or the other is the config file (app.exe.config) that Octopus generates during the deploy will point to the chosen environment of the deployment. So, in other words, if I deploy the client app to Staging, it will have its config file containing URLs of Staging. This way, the quality specialist can run tests using that specific server.
Over time I noticed that it’s annoying to deploy the same client to different environments, only to produce config files. I’d like to deploy the client one time, and have Octopus generate separate config files for all of our environments.
We currently use a combination of magic variable substitution + config transforms, within the Octopus server, at deployment time. I didn’t find out a way to force Octopus to use variables from different environments in one single deploy (example: produce app.Staging.config from staging variables, produce app.prod.config from prod variables, and so on).
I hope I made my question clear enough, if not please ask, I will clarify as needed.
Thanks for your help!
Cheers 
Hi,
Thanks for getting in touch! Unfortunately I’m not sure I fully understand your scenario. Would you be able to clarify a bit on what you’d like to accomplish?
Are you wanting to deploy just the config files and transform files, without deploying the entire app on each promotion to subsequent environments? To do this, an option may be to package up just these files into a separate NuGet package, then deploy this package to the same location for the transforms to occur, for each environment.
It sounds like you’re good to go on using variable substitution and config transforms. I’ll just give a couple of links to our blog and docs which describe some advanced scenarios. I hope it can be of some help.
I look forward to hearing back!
Best regards,
Kenny
Hi Kenny!
Hope you’re doing well
Let me try to clarify my issue.
The problem is the following:
When doing variable substitution, Octopus grabs the variables scoped to the environment of the deploy. So, deploy to QA grabs QA variables, deploy to Staging grabs Staging variables, and so on. Normally that’s great, but in my scenario it forces me to deploy the app 9 times, to 9 environments, just to generate 9 config files (the app itself is the same for all environments).
I’d like to deploy 1 time, and have that single deploy produce the app alongside the 9 config files.
Can I instruct Octopus to substitute variables with an explicitly specified environment?
So, in one single deploy, do the following:
- Substitute variables in App.QA.config with variables scoped to QA
- Substitute variables in App.Staging.config with variables scoped to Staging
- Substitute variables in App.Prod.config with variables scoped to Prod
And so on.
Or if you got other idea I’m open to suggestions of course.
Best,
Guillaume
Hi Guillaume!
Thanks for following up! I’m doing well, thank you. I hope you’re doing well too!
I’ve had a chat with my team regarding your question, but unfortunately we can’t think of a solution. Octopus isn’t able to do this. Since you deploy to each environment separately, which is a collection of deployment targets, there’s no way to perform a single deployment to all machines when they’re separated into multiple environments. And there’s no way to define your config files to substitute variables based on environment-scoping outside of the current environment you’re deploying to.
That being said, what exactly are you trying to achieve? Is it purely to avoid tediously deploying to many environments back-to-back? Knowing the 'why’s may help us in helping you find the best possible solution for your scenario.
Best regards,
Kenny
So, the goal is simply to build a client app (1 package) that has the capability to connect to all our servers (both testing and production grade).
The gain is for quality assurance specialists, so that they don’t have to deal with dozen of builds of the same client app, that connect to different environments. They could have 1 app, if that app was able to connect everywhere.
However, the app needs to have all config files to do so. We currently produce these config files using Octopus, by running a deployment to an environment.
(Importante note here: The app isn’t actually deployed to the environment (qa, staging, prod…), it’s just pushed on the QA specialist’s computer so they can test it.)
However, a deployment to that environment must still be created in Octopus in order to build the configs, and the annoying part is that it has to be done for each environment (9 times, and that produces 9 client app packages, one for each environment).
Hi Guillaume,
Thanks for following up and clarifying that. I’m sorry about my delay in getting back to you. Since Octopus doesn’t support this out of the box, I think a good solution may be to use the XML Transform using XDT library step template (written by the community). The following link is for the step template that will allow you to perform any config transforms within the step, and as a result, it should help you avoid having to promote your release through each environment to generate separate config files.
https://library.octopusdeploy.com/step-templates/569a5f1b-bb57-491a-9c4e-a6d6e44e6b26/actiontemplate-xml-transform-using-xdt
Let me know if this idea helps you, and how you go. As always, feel free to get back in touch with any further questions or concerns.
Best regards,
Kenny
Hi Kenny,
Thanks for the idea. It looks like it could definitely help. Still, my main issue remains where variable substitution (that’s being done before the config transform) can only use variables scoped to the environment targetted for the deployment.
Even using XDT to do the config transforms, I wouldn’t be able to fill the files with variables from Octopus (because, as far as I know, a deployment restricts variables to the current environment scope only).
So, what I’m saying is, would be nice to have a way to tell Octopus: “Hey, look, I know I’m deploying to Test environment right now, but don’t mind that, I will still need my client app variables scoped to QA, scoped to Staging, and scoped to Prod, so I can build the app.config files and put them on Test environment alongside the client app.”
In that example:
I hope that makes sense,
Guillaume
Hi Guillaume,
Kenny is out today so I will respond to your question. Unfortunately Octopus doesn’t support this scenario and it is not something that would be easy to introduce. Feel free to create a suggestion on UserVoice.
That being said, you could implement this yourself with a custom script but it will require a bit of effort.
High level idea:
Please, let me know if I can help in any other way.
Regards,
Pawel