Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 866
  • Last Modified:

TFS 2012: How to flag different build environments?

TFS 2012 version control question

I am new to Team Foundation Server and would like some assistance in accommodating several build environments such as Development and Production.

I am using TFS 2012 and our developers would like to flag their source code as “dev” to show that the code is currently in the development environment.

When the code is ready for production, they would like to flag it as “prod” so that another team can begin moving the code to the production environment.

Does TFS 2012 natively offer the ability to specify flags that represent different build environments?  If not, how are others accomplishing this task?
  • 2
2 Solutions
käµfm³d 👽Commented:
We use branches at our ourganization. For example, we have a DEV, UAT, and PROD branch for each of our projects. We do all of your development in the DEV branch (obviously), and when the code is ready for testing, we merge the code into the UAT branch. Then we check out that branch of code and deploy from it. This allows developers to continue developing against the DEV branch while the UAT branch is being tested. Once UAT is complete, we merge the UAT branch up to the PROD branch for similar reasons.

I learned what I know about branching and merging at my current job, so the following is information I haven't really reviewed myself, but I think it will be helpful for you:
käµfm³d 👽Commented:

We also create different Solution Configurations for each of our deployments. This allows us to quickly switch between solution/project settings when moving between environments. You can find information about this here:

The screenshots appear a bit dated, but the info is still relevant.

Also, if you are doing ASP.NET work, then built in to Visual Studio are XML Transformations. These allow you to specify XSLT transformations against your web.config files. You can use these transformations to have the settings within your web.config that can change from environment to environment be dynamically written during a build. You get one transform per solution configuration that you set up. Here's an example of what that looks like:

Each of those entries underneath the top-level web.config correspond to a solution configuration. Within each of those files, you can specify what needs to be changed. For more information on XML Transforms, you can review:

Also, if you are doing non-ASP.NET work (e.g. Windows Forms, Console applications, etc.), then Scott Hanselman's team created an extension to Visual Studio to permit the same behavior I described above within non-ASP.NET applications. This extensions is called SlowCheetah, and you can find it within the NuGet package manager. It behaves the same way as the ASP.NET utility does, except that it modifies the end-config files upon a build, whereas the ASP.NET utility only modifies config files during deployment, not build.
waltforbesSenior IT SpecialistAuthor Commented:
To Kaufmed: your answers are awesome and have great links! I am so grateful for your expert help. I will now award the full points, closing the case.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now