As I explained in my previous post, the build engine in TFS 2010 is now based on Workflow Foundation 4.0. I’ve decided to start a series on the new features of TeamBuild 2010 and will start by the creation of a new build.
In TeamBuild 2010 the build definitions has been enhanced and has new options to integrate with the new build engine. The creation of a build definition is in 6 steps:
- Build information.
- Default build parameters.
- Workflow parameters.
- Retention policy.
The information screen hasn’t change and still ask for the build name and it’s description:
The trigger section contains the previous options (Manual, Continuous Integration, Rolling builds and Schedule) and a new option “Gated Check-in”:
As specified in the small description, the “Gated check-in” can rejects all modifications to the code in the source control which could break the build. My next post will be on “Gated Check-in” and “Private builds” so I won’t explain further this option.
When the build trigger is specified you need to specified the workspace which will be used (nothing new here):
The next screen is for specifying the build controller and the drop location. This screen is the same as the one in TeamBuild 2008 excepts we specify a build controller and not a build agent. (For the difference between a controller and an agent in TeamBuild 2010 you can refer to my postTeamBuild 2010 : Architecture overview):
The next screen is new and is use to select and configure the workflow which will be use. The top section is for selecting the workflow template:
When creating a new TeamProject 3 templates are created:
- Default Template: a template which does what was done in 2008 (with some enhancements ).
- Upgrade Template: a template to use old TeamBuild 2008 scripts.
- LabDefaultTemplate: a template used for Test and Lab Management (compilation, test environment setting and tests execution).
The bottom part of the screen is use to specify the selected workflow parameters. The content is dependant on the selected workflow template:
This is where Workflow Foundation is really good, we can define a generic and configurable template which we will reuse for multiple builds. Each build custom configuration will be in his definition. The list of parameters is not static and is based on the workflow description, also the value specified in the definition are only default values and can be overridden when queuing a build manually.
The last screen is where you specify the retention policies depending on the build status and type:
Triggered and manual builds are standard build types, private builds are builds started by a developer and using the merge of the latest version and a shelveset. This enables a developer to test his code using a standard environment (the build server) before actually checking in his modification. A new option is also available for each build type and status, specifying what should be deleted when a build is deleted:
It is now possible to precisely specify what will and what won’t be deleted when a build is deleted (either manually or automatically due to retention policies).
That’s all folks Next time I’ll talk about “Gated check-in” and “Private builds”.