The purpose of this paper is to provide you background on SQL Server. It’s your self-study guide for learning fundamentals. It includes both the history of SQL and its technical basics. Concepts and definitions will form the solid foundation of your future DBA expertise.
Course Of The Month
6 days, 21 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
Suggested Solutions
zlib is a free compression library (a DLL) on which the popular gzip utility is built. In this article, we'll see how to use the zlib functions to compress and decompress data in memory; that is, without needing to use a temporary file. We'll be c…
For most people, the WrapPanel seems like a magic when they switch from WinForms to WPF. Most of us will think that the code that is used to write a control like that would be difficult. However, most of the work is done by the WPF engine, and the W…
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…
How to Install VMware Tools in Red Hat Enterprise Linux 6.4 (RHEL 6.4) Step-by-Step Tutorial
Suggested Courses
Course of the Month6 days, 21 hours left to enroll
734 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.