Continuous Integration

 < Day Day Up > 



Continuous integration is another practice that comes out of the Extreme Programming movement. If daily builds are good, XP practitioners realize, then even more frequent builds are better. After all, the sooner you spot a problem in a build, the sooner you can get to work fixing it. The logical extension of this line of reasoning is to rebuild your application every time anyone checks a change into your source code control system.

Of course, you wouldn’t want to spend all of your time doing builds by hand. That’s why people have invented continuous integration utilities. These applications monitor your source code control repository for check-ins. When they detect an updated file, they get the current code, build the project, and look for failures. With instant feedback via e-mail or a web page, they can help you be sure that no one has accidentally checked in untested code. I know of two continuous integration utilities for .NET, both of which are open-source projects:

  • CruiseControl.NET (http://ccnet.thoughtworks.com/) can work with CVS, Subversion, VSS, Perforce, StarTeam, or PVCS repositories. It integrates with NAnt for builds and NUnit for testing. It can give you immediate feedback on builds through a website, e-mail, or system tray notification.

  • Draco.NET (http://draconet.sourceforge.net/) uses CVS or VSS for source code control, and can create builds with either NAnt or VS .NET. It distributes build results via e-mail.

The main drawback that these projects have at the moment is that they don’t offer wide tool support. If you’re using Vault for source code control, or csunit for unit testing, or Visual Build Pro for your builds, they won’t help you. But if your tools are on the supported list (or you’re willing to write the code to add them), and you can spare a separate machine to be a continuous integration server, they’re worth considering for any project with multiple developers.

Warning

If you’re using continuous integration to kick off a test build process, make sure that the process doesn’t alter anything in your source code control repository. Otherwise, you can up in a situation where the continuous integration server does new builds in an endless loop, detecting its own changes and rebuilding as a result.



 < Day Day Up > 



Coder to Developer. Tools and Strategies for Delivering Your Software
Coder to Developer: Tools and Strategies for Delivering Your Software
ISBN: 078214327X
EAN: 2147483647
Year: 2003
Pages: 118

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net