Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.
One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.
COURSE of the MONTH
7 days, 19 hours left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
TFS 2012: How to flag different build environments?
Posted on 2013-01-03
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?
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
2
3 Comments
Active today
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:
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
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
Active today
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.
Featured Post
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
What my article will show is if you ever had to do processing to a listbox without being able to just select all the items in it.
My software Visual Studio 2008 crystal report v11
My issue was I wanted to add crystal report to a form and show…
Whether you've completed a degree in computer sciences or you're a self-taught programmer, writing your first lines of code in the real world is always a challenge. Here are some of the most common pitfalls for new programmers.
This is Part 3 in a 3-part series on Experts Exchange to discuss error handling in VBA code written for Excel.
Part 1 of this series discussed basic error handling code using VBA.
http://www.experts-exchange.com/videos/1478/Excel-Error-Handlin…
Do you want to know how to make a graph with Microsoft Access? First, create a query with the data for the chart. Then make a blank form and add a chart control. This video also shows how to change what data is displayed on the graph as well as form…
Suggested Courses
Course of the Month7 days, 19 hours left to enroll
765 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.