Deploying 1 package to 2 folders using different config transformations

Legacy Uncategorised
1

We have a slightly odd (okay, insane would be a better word) set of environments that we want to deploy to in our live environments. These are:

  1. DevTest
  2. Uat
  3. Partner
  4. Partner-Internal
  5. Live
  6. Live-Internal

DevTest and Uat are hosted on our dev network. We can ignore them. The other 4 are all hosted in our live environment. The workflow/lifecycle is DevTest > Uat > Partner > Live.

The code/package is the same for all of them, just the config files are different. I would prefer not to have to create 4 environments, instead I would just like two: “Partner” and “Live”. When we promote the UAT code to “Partner”, I would like it to deploy to the Partner folder using the partner config and also to the Partner-Internal folder (hosted on same box) but using the partner-internal config. Then when we promote that to “Live” it would do a similar thing and deploy the code to Live and Live-Internal using the correct configs.

Is this possible?

2

Hi Robert,

Thanks for getting in touch. I wouldn’t describe your environments as insane but it is a little bit different. :slight_smile: The best solution I can think of is to add a duplicate package step that is only run in the partner environment and live environments. The following steps outline what is required to achieve this.

  • Ensure your Octopus project has the ‘Always deploy all packages’ option set in its settings (see Screenshot 1). This will ensure Octopus deploys a second copy of your package for the internal copies.
  • Create a package step for the standard deployment through the environments and configure it appropriately (variables etc).
  • Create a duplicate package step but scope it to the partner and live environments (see Screenshot 2). This will ensure the package is deployed twice in the partner and live environments.
  • Add any variables config for the internal environments but ensure they are scoped to the duplicate step (see Screenshot 3). This is the key that will allow you to configure the internal deployment appropriately.

I tested this and it enabled me to deploy a single package twice with the appropriate config applied to each.

Hope this helps.

Rob

Screenshot1.png
Screenshot1.png1440×757 166 KB

Screenshot2.png
Screenshot2.png1329×753 186 KB

Screenshot3.png
Screenshot3.png1329×753 85.7 KB

3

Thanks for this Rob, it certainly helps.

We already have all the config files created. Are we able to use them in this scenario, rather than trying to use the variable substitution? The internal websites have markedly different services & endpoint settings in the system.serviceModel section.

Edit: Maybe Additional Transforms is what I am looking for? Create a variable that is scoped as above so that Web.Partner-Internal.config => Web.config ?

4

Hi Robert,

Thanks for the reply. I think you were on the right path. I think there are two main options.

  • Use config transforms
  • Write a small script to copy/replace the alternate config file

I’d recommend the first approach as it’s more explicit and you can consistently use transforms through your environments. If you copy/replace files, it’s more of a big bang approach and open to mistakes. Additional information on config transforms is available at the following URL.

Hope this helps!

Thanks

Rob