The more there are developers committing changes to the project source code and the more distributed they are, the more challenging it becomes to keep track of all the changes. Without having enough test coverage this is a recipe for new bugs being introduced by less experienced developers not being aware of all the project intricacies. Introducing a source control monitor notifying code owners of changes can be a good way to reduce this risk. Although there are dedicated tools available for this task, this post introduces a simple way to use your existing CruiseControl.NET setup for this task. A similar approach should be possible with other continuous integration servers as well.

This is a basic project configuration which to use for this purpose:

<project name="My Project Monitor" category="SVN Monitor">
    <sourcecontrol type="filtered">
        <sourceControlProvider type="svn">
            <autoGetSource>false</autoGetSource>
            <trunkUrl>$(SvnUrl)My Project/trunk</trunkUrl>
            <executable>$(SvnExe)</executable>
            <username>$(SvnUsername)</username>
            <password>$(SvnPassword)</password>
        </sourceControlProvider>
        <inclusionFilters>
            <pathFilter>
                <pattern>/trunk/**/*.cs</pattern>
            </pathFilter>
            <pathFilter>
                <pattern>/trunk/**/*.vb</pattern>
            </pathFilter>
        </inclusionFilters>
    </sourcecontrol>
    <triggers>
        <intervalTrigger seconds="60" />
    </triggers>
    <publishers>
        <xmllogger />
        <email from="$(MailFrom)" 
               mailhost="$(MailServer)" 
               mailhostUsername="$(MailUsername)" 
               mailhostPassword="$(MailPassword)" 
               includeDetails="true">
            <subjectSettings>
                <subject buildResult="Success" 
                         value="SVN Monitor: My Project" />
            </subjectSettings>
            <users>
                <user name="Developer 1" 
                      group="CodeOwner" 
                      address="developer.1@mycompany.com" />
            </users>
            <groups>
                <group name="CodeOwner">
                    <notifications>
                        <notificationType>Success</notificationType>
                    </notifications>
                </group>
            </groups>
        </email>
    </publishers>
</project>

A couple of things worth noticing about it:

• To simplify maintenance of a large configuration file I’m using preprocessor text constants, i.e. values for all $(ConstName) placeholders are defined at the beginning of the configuration file.
• In the sample above Subversion is used as the source control system, though CruiseControl.NET comes with built-in support most if not all source control systems available today, meaning that unlike dedicated desktop based tools you can use it no matter which and have many different source control systems you are using.
• Filtered source control block allows additional filtering of detected changes, by both including and excluding certain changes. In my case I’m simply filtering changes by file extension but there are other types of filters available as well. By additionally using a multi source control block you could also monitor multiple repositories in different source control systems with a single project.
• Setting the autoGetSource property to false, prevents the sources being retrieved from the source control system. This avoids unnecessary delays and network traffic.
• Triggers give great flexibility over how you want the notification to happen. In my case the project triggers every minute making the notification immediate but you could also configure the notification to happen less often or even only once a day at a specific time (e.g. at the beginning of the work day).
• Sending out emails to notify developers works great in enterprise scenarios when you need to notify a selected group of people. By setting the includeDetails property to true the list of changes is included in the emails being sent out. A custom email subject makes it easier for the recipients to filter the incoming emails.
• Including the default XML log publisher insures that the build logs containing all the changes are also generated on the server making it possible for everyone interested to see all past changes at a later time.