Getting Started with Continuous Integration
Configuring the Continuous Integration Server
To hook all this up to the continuous integration server requires another XML configuration file, this one for CruiseControl.NET:
<cruisecontrol> <project name="RssDrop"> <workingDirectory>c:ProjectsRssDrop</workingDirectory> <webURL>http://TITANIC/ccnet/</webURL> <triggers> <!-- Build every sixty seconds if any changes in SVN --> <intervalTrigger seconds="60" /> <!-- Force a daily build at 1AM --> <scheduleTrigger time="01:00" buildCondition="ForceBuild" /> </triggers> <modificationDelaySeconds>10</modificationDelaySeconds> <sourcecontrol type="svn"> <executable>c:program filessubversionbinsvn.exe</executable> <trunkUrl>svn://BAKUNIN/Repos/Larkware/trunk/RssDrop</trunkUrl> <autoGetSource>true</autoGetSource> <username>CCNet</username> <password>XXXXXX</password> <workingDirectory>c:ProjectsRssDrop</workingDirectory> </sourcecontrol> <tasks> <nant> <executable>C:ProjectsRssDropToolsNAntnant.exe</executable> <nologo>false</nologo> <buildFile>RssDrop.build</buildFile> <targetList> <target>ccnet</target> </targetList> <buildTimeoutSeconds>600</buildTimeoutSeconds> </nant> </tasks> <publishers> <merge> <files> <file>AutomatedBuildsFxCop.xml</file> <file>AutomatedBuildsRssDropLibUnitTests.dll-results.xml</file> <file>AutomatedBuildsCoverage.xml</file> <file>AutomatedBuildssimian.xml</file> <file>AutomatedBuildsresults-vil.xml</file> </files> </merge> <xmllogger /> </publishers> </project> </cruisecontrol>
Let's pick this apart one piece at a time. First comes some basic setup: the working directory on the build server where CruiseControl.NET will do its work and the URL on my intranet where it will publish results. Next comes the
triggers section. This specifies the events that will trigger a build. I've set up two of these. The first checks the source code repository once every minute for checkins, and starts a build if anything has changed. The second builds the code every morning at 1AM when I am (hopefully) in bed, so I get a daily record of progress.
modificationDelaySecondselement puts a ten-second delay into things so that multiple checkins in a short span of time don't trigger multiple builds; it waits until things are quiet for a little bit before getting underway.
Next comes the
tasks section, which tells CruiseControl.NET just what to do when it does decide it's time to rebuild. In this case, I've added a single task, which calls the NAnt build file that I set up earlier. More complex situations will call for multiple tasks here. CruiseControl.NET can do many things with tasks, including call NAnt, call MSBuild, call any command-line executable, invoke Visual Studio .NET directly, and so on.
publishers section of the configuration file tells the server what to do after the build. In this case, it collects all the various XML output files from the different build tools and merges them together into a single XML log file. If you're working with a team, you'll probably also want to take advantage of the server's ability to send success or failure e-mail here.
That's about all there is to setting things up. What about keeping an eye on them?
Monitoring the Results
CruiseControl.NET maintains its own IIS-based Web Dashboard for easy Web-based reporting on its activities. Figure 1 shows a sample Web report for the project that I've been examining in this article.
The Web Dashboard lets you easily move between projects on your server, see the builds for any project, and drill into the results from each tool on any build you wish. XSL transforms are used to format the tools' XML output files for pretty display. You can also force a build from the Web Dashboard, telling the server to build immediately without waiting for the triggers to activate.
The Web Dashboard is useful when you need to see the details of a particular build, but for convenient monitoring of the current build status you can't beat the CCTray application. As you might guess from the name, this little tool normally lives in the tray notification area, where it presents build status through simple color codes: green to show the last build was good, red to show it failed, and yellow to show that a build is underway. As long as the icon stays green, you know that your most recent checkin didn't break anything - and neither did a checkin from any of your co-workers.
It's All About Good Build Hygiene
Continuous integration by itself doesn't do any good, of course. You still need to write good unit tests, check in code on a regular basis, think about the architecture of your code, and so on. But coupled with other good build and development processes, it can be a powerful way to know that your code quality is staying high - or to help you immediately pinpoint problem areas when things slip. You'll need to devote a bit of time and a dedicated computer to setting things up, but you'll probably find that the rewards are worth it. With the tools being free, you've got very little to lose by trying it out!
About the Author
Mike Gunderloy is the author of over 20 books and numerous articles on development topics, and the lead developer for Larkware. Check out his latest books, Coder to Developer and Developer to Designer, both from Sybex. When he's not writing code, Mike putters in the garden on his farm in eastern Washington state.
Page 2 of 2