More continuous integration with Team Build
Earlier, I mentioned Jeff Atwood's continuous integration approach. Here are a couple more approaches.
Sondre Bjellås has decided to write his own continuous integration system for Team Build back in May (Making a Team System Automation Framework). It is called Automaton, and it's available on CodePlex.
Automaton is a Continuous Integration engine for Microsoft Team Foundation Server. Automaton will monitor your source code repository and automatically run the correct team builds that you create within Visual Studio. Build reports can be view through a web site, and your development team can get notifications on e-mail or MSN Messenger when there is problem building the source code.
Automaton supports Visual Studio 2005 and Team Foundation Server. Automaton supports only the use of Team Foundation Source Control, there is currently no support for Visual Source Safe.
Automaton is available for free and source code is licensed under Shared Source License.
In the March 2006 issue of MSDN Magazine, Ben Waldron wrote an article about his approach. His article includes the implementation as well.
Extend Team Foundation Server To Enable Continuous Integration
Many development teams have adopted "agile" methodologies to manage change and to improve software quality. These methodologies promote continuous integration as a practice to build and test software products incrementally as new features are included, bugs are fixed, and code is refactored. So how does Visual Studio® 2005 Team System and Team Foundation Server facilitate the process of agile development and continuous integration?
This article answers that question by creating an example project using agile concepts such as test-driven development (TDD) using the new unit testing features in Visual Studio 2005 Team System. After the project is completed, I'll show how to create a team project using Team Foundation Server and use this technology's extensibility features to build a custom Web service that enables continuous integration to build the application as code is checked into source control.
[Update 10/22/06] Since I wrote this post, new continuous integration add-ons have been released.
TFS Integrator by Readify
Continuous Integration (CI) is the process of continually scanning the source code repository for changes, and, once they have been detected automatically kicking off a build process to verify that the code compiles successfully.
When TFS Integrator initialises it reads a configuration file to identify which parts of the source tree it is interested in listening to then subscribes to the check-in event notifications that the eventing system sends out.
When it receives a notification it sleeps for a specified period of time then kicks off a build with the Team Build facility. Once the build is completed the eventing system sends how a notification to subscribers as to the outcome.
TeamCI by Notion Solutions
Because “Team Build”, Team Foundation Server’s Build Server, does not include any out-of-the-box mechanism to automatically start a build when a user checks files into the Source Control System, users have to manually start those builds on a regular basis. TeamCI makes this cumbersome task as easy as it can be, with a user interface that helps users quickly configure which builds execute and enables them to execute builds based on the path in the Source Control repository to which files are being checked in. What that means is that it is “smart” enough to sequentially launch one or more Team Builds based on the location of the file(s) being checked-in.
Note: Must be installed on the TFS Application-tier server. Documentation has not yet been released, check out the TeamCI Forum for updated info.
This one is an article on DevX.com: Add Continuous Integration Capabilities to Team Foundation Server
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.
by Michael Jones
