Using Continuous Integration
One of the challenges of team development is that team members work on separate parts of the code base but must eventually integrate their code with that of the other team members. Typically, a source control system is the main point of integration for source code and other developed assets. Code integration is simple if there are no or few conflicting changes, but it is difficult if there are many conflicting changes.
Understanding Conflicts
A conflict occurs when the source control system does not require an exclusive checkout and multiple developers try to check in modifications to the same file. For example, assume that developer A retrieves the latest version of a file from source control. The file has version number 1000. Then, developer B also retrieves the latest version of the file, which is still version number 1000. Next, developer B makes modifications to the file and checks it into source control. The source control system sees that developer B has modified version 1000, which is the current version. So far, there are no issues. The source control system accepts developer B's modifications and then updates the version number of the file to 1001. When developer A attempts to check in modifications to version 1000 of the file, source control informs developer A that there is a conflict because this is no longer the latest version of the file. Developer A must merge the modifications with any other modifications that have been made to the file since version 1000 was checked in.
The longer the time period before a developer synchronizes files with source control, the more likely it is that other developers have checked in conflicting changes. There are many factors that can prevent developers from performing frequent synchronizations. One issue is that many developers are unaccustomed to team development. They often wait to check in their code until they consider it to be perfect. This behavior is often driven by a fear of code reviews. Developers refuse to show their code to other team members until it is absolutely necessary. Long delays between check-ins can cause difficult merges. Another problem is that code that is not checked in is also not backed up.
Using Continuous Integration
Because long delays between synchronizations cause difficult and error-prone merge integrations, it is important to perform them frequently. It is also helpful to integrate small amounts code at a time. One of the benefits of integrating small amounts of code is that there are fewer merge conflicts, and they are easier to resolve. Another benefit is that automated build and testing processes give the developer feedback about whether the code was successfully integrated. If the build breaks, the smaller the amount of code the easier it is to isolate the problem.
The Continuous Integration Build
The process of Continuous Integration (CI) encourages developers to frequently integrate their code. It also provides the benefits of using automated build and testing processes. A CI build is typically triggered by a check-in to source control. This build validates that the latest code in source control builds successfully and passes a suite of unit tests. The CI build must include a comprehensive set of unit tests to provide any value.
To provide timely feedback, CI builds should complete quickly. CI builds can also be configured to provide code coverage and static analysis feedback. However, these are secondary goals. If they cause the CI build to take too long, configure another build process that executes less frequently to provide this information.
The CI build environment for the reference implementation applications do not perform any tests that require a live instance of SharePoint. All the unit tests use mocks that replace the actual SharePoint instance and services. Building the code and running the unit tests only requires that the following SharePoint assemblies are installed on the CI build server:
- Microsoft.SharePoint
- Microsoft.SharePoint.Security
- Microsoft.SharePoint.WorkflowActions
- Any referenced assemblies
Recommendations for Checking In Code
The following procedure shows the recommended steps to check code into source control.
To check in code to source control
- Verify that the CI build is working and passing all the unit tests. If it is not, notify the development lead. Do not check in code until the issue is resolved.
- Test all code modifications in a local development environment. Make sure that the unit tests are passing.
- Get the latest code from source control. Resolve any merge conflicts.
- Verify that the unit tests are still passing in the local development environment.
- Check in the modified files. There should be no merge conflicts because you synchronized them in step 3.
- Review the code for missing comments while the CI build is running. After the CI build completes and passes all the unit tests, you can move on to next task. If the CI build fails, fix the issue because you are now blocking other developers from integrating their code.
Tool for Running Continuous Integration Builds
The patterns & practices SharePoint Guidance team uses Microsoft Visual Studio Team System 2008 Team Foundation Server Team Build to configure and run all automated builds including CI, build verification tests, and automated acceptance tests. Another popular build platform is CruiseControl.NET. One of the most important features that both build platforms offer is a system tool that immediately issues alerts when builds break. This feature is named Build Notification in Team Build and CCTray in CruiseControl.NET.
Note
The build notification tool is only available after installing the Team Foundation Power Tools.
More Information
For an example of how to set up an automated build environment, see How to: Create an Automated Build and Deployment Solution with Team Foundation Server Team Build. For information about using Team Build while developing SharePoint Applications, see Team Development Overview. For an explanation of unit testing, see Unit Testing with Mock Objects.
For other information about CI, see Continuous Integration on Martin Fowler's Web site.
For information about setting up CI with Team Build, see TFS 2008: A basic guide to Team Build 2008 on Buck Hodges's blog.