Name of the blog

Short description of the blog

PureCM and Continuous Integration - Get Started!

Continuously rising...

Continuous Integration (CI) is one of the most frequently used practises in agile teams nowadays. According to the 3rd annual survey on “The state of agile development”, 65% of the respondents practise CI; up from 50% in 2007. This is little surprising given the advantages of CI.

All these companies are aiming to make integration a non-event in their projects. No big bang integration at the end of a project anymore. No more searching for a bug that was introduced months ago.

The role of source control

So what has PureCM got to do with it? A lot, as CI relies on a source control tool to provide information about changes made (and some more areas, which we will see later on). PureCM makes this particularly transparent, as any change made is a changeset and thus a finished task. To start with a simple example, let us look at the following (mainline development) setup:

Based on this setup, we want to introduce:

  • A mainline build for each submitted change
  • Build and unit test automation
  • Instant build result communication

While automation reduces the overhead of your CI process, team communication is definitely a key element to setup. Continuous Integration works best when a team instantly knows if a change broke the build. So you no longer waste time back-tracking to find out who broke the test doing which change.

With CI, the developer in question instantly needs to fix the change until it compiles and passes the tests. This will actually save time, as the change is still fresh in his mind. Just compare this to the situation where a bug fix is needed for a change introduced several months ago...

CruiseControl.NET server installation

I will base the following on CruiseControl.NET (CC.NET), as this tool is very popular and integrates nicely with PureCM. The first thing you need to do is to setup a clean build machine; you know why ;-). Then install CC.NET, download the PureCM plugin choosing your release and copy it into the CC.NET server directory. You can also find a quick overview about the installation process in our knowledge base.

The all powerful ccnet.config file

The single most important file to configure CC.NET is the... ccnet.config file. In this file, you can define source control integration, used build and test tools, as well as file deployment and notifications. For our example web project, we use the following example file:

<cruisecontrol>
<!-- This is your CruiseControl.NET Server Configuration file. Add your projects below! -->

  <project>
    <name>PureCM Test</name> 
    <webURL>http://ServerAddress/ccnet/</webURL>  

    <triggers> 
      <intervalTrigger name="continuous" seconds="30" initialSeconds="30"/>
    </triggers>

    <modificationDelaySeconds>2</modificationDelaySeconds>

    <sourcecontrol type="purecm">
      <workspace>C:\Documents and Settings\Administrator\My Documents\Example\Development\
          VSWebExample_CCNET</workspace>
    </sourcecontrol> 

    <tasks>
      <!-- Use MsBuild to build the .Net solution-->
      <msbuild>
        <executable>C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe</executable>
        <workingDirectory>C:\Documents and Settings\Administrator\My Documents\Example\Development\
            VSWebExample_CCNET\VSSampleWebSolution</workingDirectory>
        <projectFile>VSSampleWebSolution.sln</projectFile>
        <targets>Build</targets>
        <timeout>15</timeout>
      </msbuild>

      <!-- Use NUnit for unit testing-->
      <nunit path="C:\Program Files\NUnit 2.4.8\bin\nunit-console.exe">
        <assemblies>
        <!--Path to Visual Studio project executable-->
        <assembly>C:\Documents and Settings\Administrator\My Documents\Example\Development\
             VSWebExample_CCNET\VSSampleWebSolution\NUnitClassLibrary\bin\Debug\
             NUnitClassLibrary.dll</assembly>
        </assemblies>
      </nunit>

      <!-- Email notification to users -->
      <email from="xxx@xxx.com" mailhost="hostname" mailport="25" includeDetails="TRUE" 
           mailhostUsername="username" mailhostPassword="password" useSSL="FALSE" >
        <users>
          <!-- <user name="LeadDeveloper" group="buildmaster" address="mailto:aaa@aaa.com /> -->
          <!-- <user name="Developer1" group="developers" address="mailto:bbb@bbb.com /> -->
        </users>
        <groups>
          <!-- <group name="buildmaster" notification="always" /> -->
          <!-- <group name="developers" notification="change" /> -->
        </groups>    
      </email>

    </tasks>
  </project>
</cruisecontrol>


(Get this ccnet.config example file)

Let us have a look at the different blocks. We have just an example project, so the entry is pretty short. The <Trigger> tag allows you to define the rhythm with which CC.NET scans for changes, every 30 seconds in this example. Note that CC.NET does not support triggered builds natively, e.g. onSubmit. Now what or where exactly does CruiseControl scan?

In our mainline development example, there is just one PureCM stream where changes get submitted to. So we need to create a workspace in PureCM that allows CruiseControl to retrieve the latest revision, using the same credentials as the CC.NET service. Once set up, this workspace will get updated each time CruiseControl scans for changes, eventually triggering a build.

Obviously, you can move to the next level having a staged stream hierarchy, where CI is performed on each level. But let me talk about that in a later blog.

Setting up the build...

As CC.NET is not a build tool, you need to tell it how it can create builds. This will involve your existing build tool, which is MSBuild in our example. At this point, the config file is complete enough to get the latest changes, compile them and give us feedback about the build status. Using the web dashboard, this looks as follows (no worries, we will get back to unit testing and notifications in a minute).

You can see that each time a change is detected (“IfModificationExists”), CruiseControl.NET uses PureCM’s changeset ID to identify the build. This is where you can see why PureCM changesets are so useful, as each build gets linked to a change that anybody in your team can easily understand, find and potentially... fix.

...and unit testing

However, no CI process is complete without some testing. So we install NUnit (you can get the installers here), write a few test cases and add them to the Visual Studio solution.

Once this is done, we add the reference to the ccnet.config file to include them in the build/test cycle. As NUnit is natively supported in CC.NET, the test results will automatically appear in the web dashboard. This should look like this:

 

Email notification and the ccTray

As stated initially, you would like to communicate the results of a CI cycle back to your team, so anyone knows whether the mainline is stable or a developer has to fix a recent bug. You can do this via email as in our example, which includes a link to the web dashboard as specified in the <webURL> tag. Alternatively, you can install the ccTray that displays the status of your CI projects in the Windows Taskbar. This instant messenger like service runs real time, so you can get the current status of your CI projects with a glimpse to the lower right of your task bar.

 
ccTray, image copied from the CruiseControl Wiki

As this blog is getting longer and longer, let me just indicate the link to the CruiseControl online documentation (it is really easy!).

And finally...

So this is it – we are ready to go! I hope that this blog has facilitated your initial CI setup. Of course, the CI process might need some time to become as normal as submitting changes to PureCM for your team  ;-). But try to follow some agile principles like submitting code at least once per day, and you will quickly realise that integration in small and frequent steps not just increases codeline stability, but also productivity. And feel free to let me know about your experiences!