Run the Build
|Figure 10. Testing the Sample Project: Following a source control check-in event, the build process starts automatically.|
Now you're ready to test the configuration. Check out one of the source files in the DevXLibrary team project. Make a small modification to the source file and check it back into source control. When the check-in process completes, Team Foundation Server will call the notify.asmx
Web service, which will instruct TFS to launch the DevXLibrary project's "Continuous Integration Build." To verify that the build process started successfully, right click "Continuous Integration Build" from the list of build types, and select "Open". Figure 10
shows the Build window, which indicates that the build is initializing. Each time you build the team project, a new entry will appear in this list. Double-clicking the build labeled "Continuous Integration Build_20060910.1" opens the Build Status window shown in Figure 11
, showing the detailed status of the build.
At this point, if the build ran successfully when you checked in your code change, you've completed the process to automatically build a software project when source code is checked in.
Going a Step Further
|Figure 11. Team Build Window: The team build window shows that the build has completed.|
|Figure 12. Project Alerts Dialog: Project Alerts provide notifications for events that occur in Team Foundation Server.||
To use an automated build process in your development group, there are other things you should consider. First, it's useful to make the notify.asmx
Web service more flexible by modifying the notify.cs
file in the Web service to support other build team projects and build types. At minimum, I would suggest adding alerts to email the appropriate personnel when important steps in the build process fail. Although a detailed discussion of the possible changes is beyond the scope of this article, you can study the Web service source code and experiment with changes.
If continuous integration is too big an initial step, consider running team build on a scheduled basis. You could run a build daily or weekly, depending on your needs. There is a short article
on the MSDN web site that walks you through the process for scheduling a team project build.
Finally, you might consider subscribing the project leadership to build events so that they are notified when developers check in code, when a build process completes, or when a build's quality changes. To do this, right click the team project "DevXLibrary" and select "Project Alerts
." The Project Alerts window (see Figure 12) sends email notification when certain events occur in Team Foundation Server.
If your development group is considering an agile approach to developing software, you should definitely consider automating your build process. As with any efficient process, rapid feedback of information is critical to proper management. A continuous integration process can help by providing rapid feedback about the quality of the source code checked into source control.