CONTINUOUS INTEGRATION in Font

Encoder Code 3 of 9 in Font CONTINUOUS INTEGRATION

<build type="nant"> <baseDirectory>D:\dotNetDelivery\6\</baseDirectory> <buildArgs>-D:solution.stub=Library.Transformer -D:debug=false</buildArgs> <buildFile>Build.Core.xml</buildFile> <targetList> <target>ci</target> </targetList> <buildTimeoutSeconds>300</buildTimeoutSeconds> </build> Here we call a target called ci in the Build.Core.Xml file. This target does not exist yet, and is another change on the list for that file later on. Additionally, we will always pass through a debug value of false while operating under CI. Debug runs will be executed via the regular NAnt command line. Apart from a nant build type, other types are available. These include the VS .NET builder using a call to devenv.exe to perform the compilation and a command-line builder that allows the invocation of arbitrary functions for example, through a .bat file to perform the build. As time moves on, it is likely that support will be added for other build tools such as MSBuild, Microsoft s own build tool.

A project can be configured with a specific labeling strategy as is shown in the labeller element. CCNet can also be enhanced to handle different labeling techniques. The defaultlabeller labeler handles only a prefix and then the incremental build number that CCNet maintains elsewhere. This is different from the NAnt versioning technique that we have used up to this point, and so the build files will need to change to account for this. The script we will use is as follows: <labeller type="defaultlabeller"> <prefix>1.0.</prefix> </labeller>

Next up are a number of tasks that can be run following a successful build. These tasks are run sequentially. One example is a <nunit> task, which will perform unit testing as appropriate. This is useful if you are using a builder that is not NAnt but still want to follow the CI process; otherwise, it is probably superfluous.

Caution Mixing up the responsibilities of CCNet and NAnt could cause problems. Moving the unit-test functions into CCNet removes the ability to fully test the process outside the CCNet harness. I think it is probably best to let CCNet handle the triggering and so on, and let NAnt perform the work.

The task that is of interest to us is the <merge> task for attaching the FxCop and NUnit XML outputs to the build log of CCNet. This is easily done with a little matching, as shown here. I probably could have just used a catchall *.xml filter, but it is possible I will use other reports later on. <tasks> <merge> <files> <file> D:\dotNetDelivery\BuildAreaCI\Reports\Etomic.Library.Transformer\*-results.xml </file> <file> D:\dotNetDelivery\BuildAreaCI\Reports\Etomic.Library.Transformer\fxcop.xml </file> </files> </merge> </tasks>

Finally, once all work is complete, the build log is published in various ways. The usual method is an xmllogger, which publishes the log to the CCNet web site and dashboards. This is easily implemented in the following way: <publishers> <xmllogger /> </publishers> Another useful publisher is the email publisher. It sends an email containing the styled build log to interested parties. There are a few options for this publisher, but in general the script will look something like this: <email from="marc@etomic.co.uk" mailhost="smtp.etomic.co.uk" includeDetails="TRUE"> <projectUrl>http://localhost/ccnet</projectUrl> <users> <user name="Marc" group="buildmaster" address=marc@etomic.co.uk"/> <user name="Developer" group="developers" address="developer@etomic.co.uk"/> </users> <groups> <group name="developers" notification="change"/> <group name="buildmaster" notification="always"/> </groups> </email> This task implementation ensures that the buildmaster is always informed when a build is performed regardless of its success or failure. The developers group, however, is only informed when there has been a change in the build status for example, a shift from success to failed, or vice versa.

Note This publisher has obvious utility but is usually difficult to maintain. If you operate in an environment with many systems and rotating pools of developers (in that agile way), then adding and removing developer interests is a constant game. You may want to consider a blanket policy of everybody gets everything and then rely on the developers to filter the unimportant stuff. We see some other options in 9, too.

This completes the configuration settings we need for our projects. Because we already have a set of functioning automated build scripts and because we have enforced certain standards naming, organization, and so on then the script for all three projects is essentially identical. The most obvious differences are in details such as the interested developers for the email publisher, and whether we choose to use a multi source control for the dependent projects.