We are migrating a project to start using tenants so that we may deploy the same app with different appSettings to different environments. My question is, are there any updated ways of changing the appSettings variables in the web.config for each tenant or is the best way still to use Configuration Transformation files?
The octo admin in this thread from 2016 mentions: “Back to configuration transforms specifically, Octopus will run some of your configuration transform files automatically based on the conventions we describe here - but we haven’t currently implemented a convention that would run a transform file for a tenant, like web.TenantName.config”.
I have seen these 2 other threads here discussing the subject with Configuration Transformations from April 2018 as well:
Thanks for getting in touch! In version 4.0.8, the tenant convention for transform files was introduced, and works in the same way as the release and environment name matching (i.e. transform files named *.<tenantName>.config will match based on the tenant name you’re deploying to). Some additional information on how this naming convention works can be found in the following doc page.
However this requires you to have individual transform files for each unique tenant, so an easier approach may be to define tenant-scoped variable values, add the variable into a single transform file and target that file with the substitute variables in files feature.
I hope this helps! Let me know how you go or if you have any further questions moving forward.
Thanks for the information! It does look like the substitute variables in files feature would be best here. Very useful! Definitely glad I asked before making this harder than it needed to be.
If I do a tenanted deployment, that means that the whole project will be deployed multiple times - once for each tenant correct? I have one step that I need to deploy to 5 different targets with a small change in the config file for each. So as we previously talked about, I was thinking I could use tenanted deployments. But wouldn’t that execute the rest of the steps the exact same and essentially deploy to the other targets listed in the “Process” multiple times? Essentially doing redundant work?
I was thinking one could create 5 steps one after another in the process. Then could use variable replacement and transform files each step to make sure that same service has the config files changed for the new Target.
I was also thinking that one could assign all of the Targets in the process to ONE tenant and have the other 4 tenants assigned to their respective Targets for the service they are running. That way when deploying the first tenant would deploy the other services to their respective targets and the duplicated service to theirs without deploying the other services multiple times to the same target.
For clarification:
We have several services being deployed that all work together in our process as a flow, each service a prerequisite to the others, in an order. All of those services but 2 need to be deployed to one machine. Those other 2 services need deployed to multiple machines, each machine is a dedicated machine for a customer for that service in the flow so that we don’t have all customers on one machine and overloading it. Otherwise, all of the customers use the same machine for the rest of the steps.
Hopefully that is helpful enough to understand what I’m trying to do!
This is what I believe will be the best route for us to go using a Configuration Transformation file and variable replacement. This may also be a little more clear of the process. All customers will be using the same first 4 steps machines for those services: WebSvc1 on machine1, WebSvc2 on machine2, WebSvc3 on machine3, WindowsSvc1 on machine4, WindowsSvc4 on machine10, and WindowsSvc5 on machine11. They will have their own independent machine for WindowsSvc2 and WindowsSvc3:
Deploy WebSvc1 to machine1
Deploy WebSvc2 to machine2
Deploy WebSvc3 to machine3
Deploy WindowsSvc1 to machine4
Deploy WindowsSvc2 to machine5 after applying config transform for customer1
Deploy WindowsSvc2 to machine6 after applying config transform for customer2
Deploy WindowsSvc2 to machine7 after applying config transform for customer3
Deploy WindowsSvc2 to machine8 after applying config transform for customer4
Deploy WindowsSvc2 to machine9 after applying config transform for customer5
Deploy WindowsSvc3 to machine10 after applying config transform for customer1
Deploy WindowsSvc3 to machine11 after applying config transform for customer2
Deploy WindowsSvc4 to machine12
Deploy WindowsSvc5 to machine13
However, I have a question after reading the documentation here: https://octopus.com/docs/deployment-process/configuration-features/configuration-transforms
I’m assuming, according to the doc, we will have to create a Configuration Transformation file for each Windows Service since they have different names, correct? So essentialy I would create a Config Transform file for WindowsSvc2 above and use variable replacement when deploying it for that customer’s machine to ensure the proper value has been changed?
Thanks for following up! It looks like you’re right on the money. A transform file per service, and variable substitution to get tenant-specific values replaced within each service’s transform file sounds like the best way to approach it.
Let me know how you go, or if you have any further questions or concerns along the way.
