Code Reviews using Subversion

I am a big fan of code reviews.  Code reviews are important for ensuring good design principles and to make sure that BAC (buggy ass code) doesn't make its way into your application.  I have recently adopted a model that I am sure the open source community is familiar with, which is using Subversion patches as a means by which to conduct code reviews.  The process is divided into a few component tasks.  One of the biggest parts of this process is the developer that is making the code change, major system enchancement or whatever will create their own feature branch in subversion.  If you are not sure how to create a branch the TortiseSVN guide, or the Subversion guide (if you are a command line junkie) are informative on this subject.

So lets step through a simple example.  Lets say I need to cut a feature branch off of the trunk.  I have a local working copy of the trunk in a directory c:\trunk.  I then use my tool of choice to create a branch call NewFeatureBranch from this working copy (You are actually creating a branch from the subversion trunk).   Then you create a directory structure of your liking on your local machine to check this new branch into.  What I typically do is create a directory hierarchy that represents the release you are working toward, so for example if I am working on a feature in the 3.1 release of my product I will have a directory named c:\ProductName_V3x0x1\NewFeatureBranch.

The c:\ProductNameV3x0x1\NewFeatureBranch is the working copy you will make all of your changes in.  Feel free to check in, roll-back, add new libraries in this working copy, or whaever you need to implement the feature.  When you are ready for code review it is time to do two things.  First update your working copy of the trunk so that it is completely green.  In other words there are no differences between the working copy of the trunk and the subversion repository.  Next merge from your branch to your working copy of the trunk (or the branch you cut from).  When you perform this function you may have conflicts and you will definately have changes.  Address all of the conflicts accordingly and then use subversion to create a patch from the root of your project.  A patch in subversion terms is simply a collection of all of the diffs of your code.  If you follow this process the patch will only contain your diffs and this patch can be circulated for code reviews.

The person who receives your patch will always perform an update on the trunk (or whereever you cut your branch from) before performing the review.  Once the update is complete the code reviewer will by convention apply the patch to the root of the project unless you tell them otherwise.  This will enable the reviewer to see the diffs of your code, make comments in your code and submit a patch to you with either code changes, comments etc.  This process has worked very well for me in the past, and I continue to use it today.

Powered by Qumana

NANT Scripts Rock

I recently had the fortunate opportunity to be given a project of my own to work on.  I would say that Agile practices are extremely important to me and I do my best to put these into practice every day.  Currently we use CruiseControl.NET as out continuous integration server and I wanted to get our tests integrated into the process, so I decided to create a new build script and create a new cruise control project for this purpose.  For those of you who are pausing and saying...What,  you do not have your tests integrated into your build.  I agree.  Sometimes things take a little longer to get into place than we would like, but we are getting there slowly but surely.

I must say that after my experience today I have an even higher level of respect for build/release engineers.  It took me all day to get the nant script to do as I wanted it to do and to get the test results output I desired.  As a practice we keep all of our test projects in a directory named tests at the root of our directory hierarchy.  I created a new solution that contained only the tests that I wanted to integrate into the build.

The build script runs msbuild on the solution file and then does some magic to copy the directory structure into a build-temp directory which is the directory where the nunit-console.exe is applied to the dll.  The process is broken into a number of tasks namely build the solution, copy the test project structure to a build-temp directory, run nunit-console.exe on the test dll's and then copy the results of those tests to the test-results directory.  The script looks a little like this:

This copies the results of the build into a build-temp directory

<target name="copy-tests" depends="build">
     <echo message="Copying tests to ${build.dir}\tests" />
     <mkdir dir="${build.dir}\tests"/>
     <copy todir="${build.dir}\tests">
        <fileset basedir="tests" failonempty="true">
          <include name="*PatternOfTestsToInclude*/**"/>
        </fileset>
    </copy>
</target>

This iterates through the directories and executes nunit-console.exe on each Test dll file.  It moves the results of the test to the test.results directory

<target name="tests" depends="copy-tests">
     <echo message="Create directory ${results.dir}"/>
     <mkdir dir="${results.dir}"/>
     <echo message="Create directory ${test.results}"/>
     <mkdir dir="${test.results}"/>
     <echo message="Running Nunit Tests"/>
     <foreach item="Folder" property="foldername">
         <in>
             <items>
                 <include name="${build.dir}\tests\*"/>
             </items>
         </in>
        <do>
            <echo message="Iterating through folder ${foldername}\bin\${build-configuration}"/>
            <foreach item="File" property="filename">
                <in>
                    <items>
                         <include name="${foldername}\bin\${build-configuration}\*Test*.dll"/>
                    </items>
                </in>
        <do>
            <echo message="Running test for file ${filename}"/>
            <echo message="Writing test results to test-results.xml for dll ${filename}"/>
            <exec program="${nunit-console.exe}" failonerror="false" resultproperty="testresult">
                <arg value="${filename}"/>
                <arg value="/xml=test-results.xml" />
            </exec>
            <property name="niceFileName" value="${path::get-file-name-without-extension(filename)}"/>
            <move
                 file="test-results.xml"
                 tofile="${test.results}\${niceFileName}-test-results.xml"
                 overwrite="true"/>
            <fail message="Failures reported in unit test for ${filename}." unless="${int::parse(testresult)==0}" />
        </do>
    </foreach>
</do></foreach></target>

This approach is cool because I can inject into the script the pattern I want to use to select the test groups I want as a part of my test suite.  In my situation this makes sense because I only want those tests that are specific to my project.  As long as you use some standard naming conventions for your tests then you are good.

Powered by Qumana

A Week of Losses and Gains

This is my first post so I will start out by introducing myself.  My name is Michael and I am a C# Developer for a company that will remain nameless in Jacksonville, FL.  I have worked in the software development world for about 10 years and have taken up .NET development for the past 3.5 years.  This blog will contain some development insights as well as some a collection of comedic elements of my life.

To start off with, the name of this blog is based on a Pixies song that I like.  If you have not heard of it look it up.  I have been listening to more Frank Black and the Pixies as of late so that gave me the inspiration for the Blog name.

As far as the title of this blog it has certainly been a week of losses and gains.  My wife and I recently order some new furniture for our daughters room (aka Sarah) and in the process decided to do a number of other things such as:

• Replace the carpet in 3 rooms in our house including Sarah's room


• Re-Paint our Sarah's room

This sounds quite simple, but wait a moment human beings are involved in this process, so let the games begin.  To make a very long story short the furniture was delivered damaged.  In the process of the delivery the new carpet was damaged, so Sarah who has been very anxious to get comfy in her new bed is still waiting.  The good news is that this will all work itself out eventually and we just signed up for a new dog.

All good parents know that re-direction can sometimes be a good thing, and this certainly worked.  The furniture and the carpet situation should be worked out next week, and all will be well with the world.  Until our new family member starts howling in the middle of the night to go to the bathroom.

This is enough for now and I hope top have some technical stuff soon on this blog, but this is my chance to inform the masses of one or maybe even two that I am here.

Powered by Qumana