As I already did with several popular.NET projects like NUnit, NHibernate, .NET Framework, Silverlight, I found interesting to see what we can say about their architecture, structure and quality. To do so, I use the static analyzer NDepend and sometime I have the chance to debate with some developers of these products. Today, I would like to focus on the CruiseControl.NET code base. CruiseControl.NET is an Automated Continuous Integration server, implemented using the Microsoft .NET Framework. It is developed by the company ThoughtWorks.

With 13 152 lines of C# code, CC.NET is a relatively small code base. Here are the global key metrics obtained from the CC.NET code base :

# IL instructions    86 168

# lines of code (LOC)    13 152

# lines of comment    5 996

Percentage Comment    31%

# Assemblies    8

# Namespaces    52

# Types    634

# Methods    4 030

# Fields    1 867

Coverage:

Percentage Coverage    37%

# Lines of Code Covered    4 944

# Lines of Code Not Covered    8 208

Tier code used by the application:

# Tier Assemblies used    14

# Namespaces used    57

# Types used    442

# Methods used    1 235

# Fields used    72

Test Coverage of CruiseControl.NET

It comes with 919 unit tests, on which 17 are failing when I open the main VS solution, rebuild all, and start testing with TestDriven.NET. 37% of the code base is covered which is not so much. However a lot of effort has been put in unit testing considering that the test assembly ThoughtWorks.CruiseControl.UnitTests weights 13 717 lines of code alone, more than the code base tested. Also, we can see that the tests are focused on some particular parts of the code. When a part of the code is tested, it is more than 80% covered.

On the NDepend Metric view below, rectangles represents methods and the size of a rectangle is proportional to the number of lines of code of the underlying method. Rectangles methods are hierarchized by types, namespaces and assemblies. Blue rectangles represents methods at least 80% covered, as indicated by the CQL Query below.

Architecture of CruiseControl.NET

The bulk of the code is spawned on 3 assemblies: Core, CCTrayLib and WebDashboard.

SELECT ASSEMBLIES WHERE !IsFrameworkAssembly ORDER BY NbLinesOfCode DESC 

Here is the dependency graph of assemblies:

The code base is nicely partitioned through assemblies, with few assemblies, but larger. As often in such situation, the downside is that the code in each big assembly is entangled. Here are the namespaces of CC.NET seen from the NDepend dependency matrix. There are 2 massive dependency cycles (represented with red square):

Here what looks like such a cycle. Clearly the namespace ThoughtWorks.CruiseControl.WebDashboard.Dashboard is pretty entangled and some important refactoring is needed here:

And here is a focus on a cycle involving two namespaces. These kind of focus are good helpers to let the team decide where the cycle should be cut. Here, the first thing to do is to remove double-arrows (in red) and then decide where the cycle should be cut by using some abstractions.

To obtain such focus on a cycle involving two namespaces from VisualNDepend, the easiest way is to set the indirect dependencies mode in the dependency matrix and to click on the cell corresponding to the 2 namespaces. The weight  of the black cell indicates here a dependency cycle with a minimal length 7:

Bad usage of Copy Local Reference Assembly option set to True

Unfortunately, as in most .NET code bases, CC.Net VS projects rely on the copy local reference assembly option set to true.

While dissecting the NUnit code base I demonstrated that setting this option to true is a bad thing. It is easy to see that assemblies get over-duplicated by doing a search on the root path.

Not only this increase significantly the compilation time (x3 in the case of NUnit), but also it messes up your working environment. Last but not least, doing so introduces the risk for versioning potential problems. Btw, NDepend will emit a warning if it founds 2 assemblies in 2 different directories with the same name, but not the same content or version.

The right thing to do is to define 2 directories $RootDir$\bin\Debug and $RootDir$\bin\Release, and configure your VisualStudio projects to emit assemblies in these directories. All project references should reference assemblies in the Debug directory. As a bonus, you have the possibility to emit your tests assemblies in the $RootDir$\bin directory. This way, with the astute of assembly config files, applications assemblies can be tested easily. Such a config file can look like this (you can add as many relative sub dir as needed through the privatePath attribute):

<?xml version="1.0" encoding="utf-8" ?> <configuration> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <probing privatePath="Debug;Debug\Lib" /> </assemblyBinding> </runtime> </configuration>

By setting this option to true by default, Microsoft fosters bad practices on the usage of Visual Studio.

CruiseControl Quality

The CC.NET code base overall quality is pretty good considering classical metrics. Only 75 methods on 4 030 slightly exceed thresholds (the report tells 5 265 methods because it includes tier code methods).

WARN IF Count > 0 IN SELECT METHODS WHERE 
!NameIs "InitializeComponent()" AND
                                           // Metrics' definitions
     (  NbLinesOfCode > 30 OR              // http://www.ndepend.com/Metrics.aspx#NbLinesOfCode
        NbILInstructions > 200 OR          // http://www.ndepend.com/Metrics.aspx#NbILInstructions
        CyclomaticComplexity > 20 OR       // http://www.ndepend.com/Metrics.aspx#CC
        ILCyclomaticComplexity > 50 OR     // http://www.ndepend.com/Metrics.aspx#ILCC
        ILNestingDepth > 4 OR              // http://www.ndepend.com/Metrics.aspx#ILNestingDepth
        NbParameters > 5 OR                // http://www.ndepend.com/Metrics.aspx#NbParameters
        NbVariables > 8  )                 // http://www.ndepend.com/Metrics.aspx#NbVariables