The ideas here is to “own” your continous integration process and make it work for you. Afterall, you spent some time setting up CruiseControl.Net and it’s ticking along nicely. At some stage, you need to make it “yours” and let it reflect your needs in terms of your process and record build data that you use [need] to make decisions.
<soapbox>
In fact, i’d encourage you to really push into making it your own. Not just the look ‘n feel- but the real nitty gritty. Define and extend and experiment with your continuous integration process to make it add value…
</soapbox>
the Scenario
Our automated build process runs a series of tests against a database. Before we start the tests, we need to record some information about the database; this being gathered by means of a stored procedure. We also need to persist the results as part of the build so we can monitor trends.
the Tools
* Nant build script
* Nant custom user task
* stored procedure
* xslt template
* cc.net config files
The Nant build script is included as part of the build process kickstarted by the bootstrap.build configured in cc. For more information on setting up cc.net, review the documentation that comes as part of the distribution. The ccnet.config file should include a nant <node> under tasks, similar to this…
<nant>
<executable>C:\nant-0.85\bin\nant.exe</executable>
<buildArgs>-D:debug=false</buildArgs>
<buildFile>bootstrap.build</buildFile>
<targetList>
<target>go</target>
</targetList>
</nant>
The Nant build script then calls a Nant custom user task which has the responsibility of executing the stored procedure and formatting the results into an xml file. To execute the custom task, somewhere along your build path, you will include something like…
<project name="ccnetLaunch" default="go">
<target name="go">
<loadtasks assembly="${nant::get-base-directory()}/mytask.dll" />
<myTask ConnectionString="MY_CONNECTION_STRING" SqlStatement="sp_myTask"
LogFile="myTask.xml" />
</target>
</project>
<loadtasks/> helps define <myTask/> which is built into an assembly and in this case, placed into the nant/bin directory. The nant custom user task is straightforward and the nant distribution includes a basic template sample which you can follow easily enough. another sample here
The xml output file itself is then merged into the cc build report. Again, your ccnet.config file handles this easily with…
<publishers>
<merge>
<files>
<file>myTask.xml</file>
</files>
</merge>
<xmllogger />
</publishers>
Finally, you need to add the xslt which transforms the xml output into the cc.net dashboard. Add the xslt file to the webdashboard xslt folder and append to the dashboard.config file, something similar to this…
<xslReportBuildPlugin description="My Results" actionName="MyDataReport" xslFileName="xsl\mytask.xsl" />
Now each build successfully calls your custom user task, saves the result of the stored procedure to an xml file which is merged into the build output and accessible from the dashboard for as long as you got build logs 🙂
Following this concept should give you an idea of how to start owning your process and not just going with the stock standard install. Set it up, take some risks and call it your own.
