5

The organisation I work for currently uses web deploy to release to different environments. Configuration of web applications (connection strings, service url's, and so on) is managed using solution configurations, with associated app.config transforms. With debug, three test environments and production, there are five solution configurations (four transforms). When deploying to an environment, web deploy builds the solutions against the selected configuration and then deploys it using the appropriate transform.

I am trying to move us to using a more sophisticated build and release management process. The company is heavily wedded to using Microsoft tooling and has agreed subject to using TFS Build 2015 (on premise).

The current process appears to me to be unsuitable for use in conjunction with a CI/CD approach and TFS release management. I'm unconvinced that a build tested in one solution configuration should be rebuilt and promoted in a different solution configuration. The other concern is that this would be maintenance heavy, requiring separate Build Definitions and therefore Release Definitions for each environment.

I envisage that only two solution configurations should be used (debug and release). Check-in to the development branch would automatically kick off a CI build using debug configuration. To start with, deployment would require a manual build in release mode. The Release Definition could then be used to promote this build to each environment with the relevant application configuration as required.

Eventually the goal would be to automate deployment into the first stage of testing (for example through merge into a release branch). It may also be useful to extend to catering for a third solution configuration that deploys into an environment for running automated tests.

My questions are:

  • Is my belief that it is preferable not to rebuild for each environment reasonable?
  • Is this a suitable approach to achieve my objectives, or have I missed a different/better approach?
  • If following this approach, is it considered preferable to leave the solution configurations in place (for the app.config transforms), just using debug/release for the build and then transforming as part of the release job? Or is it better to manage the configuration through the Release Definition environment variables (we do not have centralised configuration management)?
1

I think you're on the right track.

Is my belief that it is preferable not to rebuild for each environment reasonable?

You are correct. You should build once and deploy the same artifacts to each environment, changing only the configuration data.

Is this a suitable approach to achieve my objectives, or have I missed a different/better approach?

What you have described (two solution configurations, promoting a build with the relevant application configuration) is a good solution, in my opinion.

If following this approach, is it considered preferable to leave the solution configurations in place (for the app.config transforms), just using debug/release for the build and then transforming as part of the release job? Or is it better to manage the configuration through the Release Definition environment variables (we do not have centralised configuration management)?

I think it is fine to leave the debug and release configurations in place. You can use variable groups or simply store the environment-specific configuration files in a secure location, pulling them as needed during releases. Use whatever is easier for you to maintain.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.