Backup is strategic to your business because your data is strategic to your business. Without backup, your business will fail. This white paper explains why it is vital for you to design and immediately execute a backup strategy to protect 100 percent of your data.
Course Of The Month
6 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
This is a fairly complicated script that will install the required prerequisites to install SCCM 2012 R2 on a server. It was designed under the functional model in order to compartmentalize each step required, reducing the overall complexity. The …
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 Month6 days, 19 hours left to enroll
Earn Certification
Administering Microsoft SQL Server 2012 Databases (Exam 70-462)
$79.00$71.10
726 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.