Good Strategy: Set up Multiple TFS Build Definitions for Multiple Environments

In order to fully use TFS Build Automation for our multiple environments, currently we set up 3 TFS Build Dentitions as follows.  

Branch & Environment	TFS Build Definition
DEV	Source Control Folder points to DEV Project in DEV environment (Web.config and service reference points to DEV)
TEST	Source Control Folder points to DEV Project in TEST environment (Web.config and service reference points to TEST)
STAGE	Source Control Folder points to DEV Project in STAGE environment (Web.config and service reference points to STAGE)
PROD	We don’t set up definition in PROD because it is not allowed for us to do so.

In order to implement Unit Tests, WCF Tests, DB Tests and Coded Web Tests in TFS build definitions above, I need to create a TEST project that adds 3 different addresses (URLs) in service reference for multiple environments. I also need to add 3 Test lists called BVTDEV, BVTTEST and BVTSTAGE in Test List Editor and put required tests inside them separately.

Therefore, one TEST Project with different Test List is always available for all environments.

Branch & Environment	TFS build Definition
DEV	Source Control Folder points to DEV Project in DEV environment Source Control Folder points to TEST Project in DEV environment  (Test List to run: select BVTDEV)
TEST	Source Control Folder points to DEV Project in TEST environment Source Control Folder points to TEST Project in TEST environment (Test List to run: select BVTTEST)
STAGE	Source Control Folder points to DEV Project in STAGE environment Source Control Folder points to TEST Project in STAGE environment (Test List to run: select BVTSTAGE)
PROD	We don’t set up definition in PROD because it is not allowed for us to do so.

From our previous experience, when we push the code from DEV to TEST or from TEST to STAGE environment, DB changes always cause the issue and those BVTs can help us quickly capture if it is a good build or not.

I know some people would like to use 1 build definition for multiple environments. I don’t recommend it because different environment has different configuration and different service reference address. For TFS reporting, we can also know the build quality status for DEV /TEST / STAGE.

Setting up multiple TFS build definitions for multiple environments is a wonderful strategy for our current Silverlight 5 Project.