In the recent past, it was common for Windows applications to be manually compiled and built directly on a developer's desktop computer. This caused many problems.

For example, the developer may have had a different version of a component used in the application, or you couldn't build when he was on vacation let alone left the company, and it introduced a high degree of error if the developer made changes for future features (or testing code) without realizing it was included in the build.

The next evolutionary phase was "The Build Machine," a dedicated machine for the build. However, the effort of actually building applications was largely either manual or a custom "one-off" automated process. Integrating the efforts of a team of developers was often a painful process because this was the first time their code was tested as an integrated unit.

In the early 2000s, when Microsoft developers began migrating to the .NET platform, a new software methodology called "Extreme Programming" was emerging. One of its 12 core processes was called "Continuous Integration," which was designed to solve the problems described above.

Prior to the first release of Team Foundation Server 2005, many .NET developers used CI, but this required integrating a number of different tools. Most of these tools were open source, with varying degrees of features, integration, and support. TFS offers an enormous advantage: it's fully integrated with Visual Studio, with the complete support of Microsoft and its surrounding community of blogs and forums. Add to that the rich features of TFS beyond build and CI - particularly the integration of build data in the TFS Data Warehouse, which allows detailed metrics for software quality - and TFS becomes a compelling choice even for users who have successfully implemented their builds without it.

Whether or not one is a proponent of what is now called "Agile Methodologies," CI practices are widely considered "best practices" and are easily incorporated into any development methodology. While not all of those practices may be desirable or practical for all development groups, they're easily incorporated as core features of Team Foundation Server. This is particularly true given the enhancements introduced with the VSTS 2008 "Orcas" release.

As described by the "guru" of XP, Martin Fowler, at http://www.martinfowler.com/articles/continuousIntegration.html, Continuous Integration is defined as: 1) A single source repository; 2) An automated build; 3) A self-testing build; 4) Daily commits across the project team; 5) Every commit builds its mainline on an integration machine; 6) Keep the build fast; 7) Test in a clone of the production environment; 8) Make it easy for everyone to get the latest executables; 9) Everyone can see what's happening; and 10) Automate deployment.

Let's take a look at these 10 practices and how they can be implemented in TFS 2008.

Single Source Repository
A discussion of the features of the TFS Version Control could fill entire articles (or books!) Suffice it to say, this component is widely considered the best on the market - many Java shops use it. The Version Control component is worth the cost of the TFS license alone! (But it would be a huge waste to use TFS only for version control.)

The Source repository is implemented using SQL Server, allowing atomic transactions on check-ins; distributed development teams; easy backup; and no fear of "corruption" on large repositories. Branch and Merge is a strength, not a feature to be avoided.