RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Add Continuous Integration Capabilities to Team Foundation Server : Page 4

Continuous Integration is an agile process that rebuilds a project whenever the underlying code changes. Find out how to modify your Team Foundation Server projects' "build types" to implement continuous integration features such as automatic builds, testing, and problem notification.

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.

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.
Going a Step Further
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.

Michael S. Jones is the Director of Systems Architecture for Passport Health Communications, Inc., a national healthcare technology provider connecting hospitals, physician clinics and outpatient centers with payer and patient information to facilitate and improve their revenue cycle process. Michael, his wife, and three children live in Franklin, Tennessee where he spends his spare time reading and enjoying time with his family outdoors. .
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date