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.