Team Foundation Server 2012 provides great features supporting automation of processes during a application lifecycle. This blog post wants to give a short introduction to automate the build process for SharePoint 2010 solutions.
Generally, the following topics will be covered within this and the following blog posts:
- TFS Build Process & Templates – short introduction (<—here you are)
- Integrating SPDisposeCheck
- Integrating FxCop (coming soon)
- Integrating StyleCop (coming soon)
TFS Build Process & Templates – short introduction
TFS 2012 uses Workflow Foundation 4 to manage build processes. The build workflows are declaratively described in XAML files and can easily be extended or changed.
With the creation of a new Team Project, a new folder “BuildProcessTemplates” is added to the project. The files are stored and versioned like all other source code files in the project. The following items are created automatically:
- AzureContinuousDeployment.11.xaml (used to deploy against Azure –> info)
- DefaultTemplate.11.1.xaml (used for “normal” builds)
- LabDefaultTemplate.11.xaml (used to bring in Lab Environments –> info)
- UpgradeTemplate.xaml (used for older versions of TFS, makes more calls to MSBuild, less to WF)
Because we are developing for a SharePoint 2010 environment and we are starting on a green field, we are using DefaultTemplate.11.1.xaml as our template for a new build process.
Creating new Build Process
Usually, you start by copying an existing build process template to modify it to your special needs. I simply started by creating a new build process definition by copying the existing DefaultTemplate.11.1.xaml file. The option appears during the creation of a new build definition:
The file will be stored next to the other templates in the “BuildProcessTemplates” folder. Afterwards you can open the Workflow in Visual Studio by double clicking the XAML file. Make sure you click “Collapse All” at the beginning…
You will be presented with the following workflow. The details are explained below.
1. Get the build (GetBuildDetail Activity)
In this first step, the details about the build are being requested from the agent. The interface IBuildDetail describes the properties the resulting variable will provide. You can access the properties via the BuildDetail-variable within the workflow, like BuildDetail.DropLocation.
2. Update drop location
In this sequence, the drop location will be calculated and set. The new build will be stored into this newly created subfolder. The folder name is created as follow:
BuildDetail.DropLocationRoot + BuildDetail.BuildDefinition.Name + BuildDetail.BuildNumber
3. Run on agent
This is the build process itself. Variables will be initialized, the workspace gets configured for a new build, source code is compiled and tests get executed. Take a look inside this sequences since this is the most interesting part for later changes.
4. Check in Gated Changes for CheckInShelveset Builds
If there was no error during build and tests, the gated changes are checked in into the repository. This prevents developers from checking in changes that cannot be compiled or will not pass the tests. More information about gated check-ins are available here.