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.
TFS 2012: How to flag different build environments?
Subject:
TFS 2012 version control question
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?
TFS 2012 version control question
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?
Asked:
2
2 Solutions
P.S.
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:
http://msdn.microsoft.com/en-us/library/bb166577.aspx
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:
http://msdn.microsoft.com/en-us/library/dd465326.aspx
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.
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:
http://msdn.microsoft.com/en-us/library/bb166577.aspx
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:
http://msdn.microsoft.com/en-us/library/dd465326.aspx
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.
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 Already a member? Login.
Featured Post
Tackle projects and never again get stuck behind a technical roadblock.
Join Now
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:
http://vsarbranchingguide.codeplex.com/
http://msdn.microsoft.com/en-us/magazine/gg598921.aspx
http://blogs.msdn.com/b/lukad/archive/2010/01/18/visual-studio-tfs-branching-guide-2010.aspx