Home/ Questions/Q 9217433
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-18T02:37:58+00:00

I am working on a CI process with automated deployment. TFS Build is building

  • 0

I am working on a CI process with automated deployment. TFS Build is building the solution, and it then uses an InvokeProcess task to kick off a Powershell script. The Powershell script deploys the database changes as a dacpac using sqlpackage, reporting services reports using the web service, fonts to the SSRS server, and the website itself to 1 or more web servers – the whole process uses a deployment configuration file to define drop paths, server ips, installation folders etc. There will be one of these per environment.

I would like to be able to build the solution and deploy to an internal server to run automated tests as part of the automated build. Once tests are completed, and the build has been manually checked, I’d then like to be able to kick off another Build definition which only has the deployment portion of the standard build template, which will simply take a build number or build drop location, and deploy the same build to a different environment (i.e. staging, prod etc.)

The issue I have is that I’m currently managing most of my web/app configuration using config file transformation – i.e. I have build definitions for Debug, Test, Prod etc. and then Web.Debug.config, Web.Test.config etc. I only want to carry out one build, and then deploy that same build to different environments, however at the moment the build will only generate configuration files for one environment – i.e. whatever the build configuration is.

Would the best approach be to generate all config files (or actually pre-createg complete config files for each environment), and then just choose the appropriate one for the specific deployment? Or should I store the env specific config in my deployment configuration file and update the appropriate keys using powershell when deploying?

What would be the normal/recommended approach here?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’d suggest creating new Configurations for each target environment (e.g. by default you have Debug/Release, create some more). Then use the built-in web.config transforms, for non web-projects use Slow Cheetah

    This will spit out pre-configured build outputs for each configuration you specify you want build (in your Build Definition).

    • 0