The reason why it stood out is that at the time we only had a very rudimentary build system and it was bugging me that we could not go from source to installers (including build # and documentation) without someone getting involved to hand crank it. Doing it that always ended up with inconsistency and we would end up testing software builds that had the wrong DLLs in it and simply just waste some testing time.

The decision was made to create a new build system and efforts started on getting it implemented. Unfortunately, along with the decision to implement a build system also came the decision to implement all of the functionality ourselves rather than use 3rd party OR open source tools. Due to this, the build system got half built before we realized that it was not maintainable and the project suspended.

I mention this in the hope that others do not suffer this growing pain as we did. It is also the case that at the time the tools we know use did not exist or certainly were not ready for reliable use so perhaps we just tried to it before the most optimum time.

Ok. So about a year later I started looking at this problem again and found some interesting tools out there that people were recommending.

• Nant
• CruiseControl.NET

Nant

Nant is a open source .NET build system which finds it’s home on sourceforge. At the time of looking we had started to move all of our code from VB/C++ over to C# so standardizing on a build system that is .NET based is fairly good one.

We still have to this day a set of components that are VB so it was important that it would support VB. Thankfully we are not the only company in the world that still have VB code and there is a vb6 task as part of the Nant Contrib project. This allowed us to have our VB6 projects compiled in the same build environment as our C# projects.

Nant allows for a great level of control on what is built and what is used to build it.

CruiseControl.NET

CruiseControl.NET (CC.NET) is a continuous integration server that watches your source control system and recognizes when changes have been made on a configured sub folder triggers a process to begin. In our case this process is a nant build task on the piece of functionality that has changed.

The great thing about this is that you get immediate feedback on all code checked in that it did not break anything. This can be anything from a new source file missing to breaking a build on a different version of ArcGIS (more on this later).

There are web-based and windows notification area (system tray) tools that allow anyone to see the current state of the build system.

To make the ‘test builds’ quick and painless we have separated the build files into product/project and even component level. This means that if we change component Y in project X then only that project will be built and not the whole source tree (which takes about 20 minutes and would be over the top for every check-in!). Due to this we have about 30 projects in each build server (up to 3 at any time — more later).

In the early hours of the morning we also have a batch build script triggered within CC.NET that builds all of the software in order, creates the installers and server folder structures for testing. This process takes anywhere up to about 30 minutes and again as it is within the build system we know whether it as built successfully when we log in every morning.

Build Servers

I mentioned that we have up to 3 build servers. Why on earth would we even contemplate having more than one you say? The simple and only reason that we have up to 3 is to support each version of ArcGIS. When using .NET the libraries referenced are version encoded so we made the decision to build the same source code in all of the versions that we currently support. There are ways of work within versioned assemblies (use of policy files for example) but we felt that it would be good to build on the actual version the user will be running the software on so the build servers were born.

What is the result of the build?

Well, that depends on what build we are talking about.

For a build that is triggered by a Subversion check-in just the component of software that has been changed is built. There *should* be a subsequent build of all components that depend on that particular assembly (or set of assemblies) but this is not supported in CC.NET and we have not encoded that logic in Nant as yet.

For a ‘batch build’ that has been triggered in the evening the Nant script:

• Increments the build number is all of the AssemblyInfo.cs files
• Builds all of the projects we want built
• Reverts the AssemblyInfo.cs files so that they do not show up in SVN as edited.
• Generates Installers for all of the products we have
• Copies the installers to a well defined location

All of this is very important to a software team as it means that all of the tedious tasks that are prone to error are automated. This means we cannot get it wrong (well kind of) and we can be sleeping when it is being done (batch build is triggered at 12:30 AM).

That would usually be OK. I have a clean VPC image of ArcGIS 9.1 and dev environment so normally I would just synchronize the source code and I am off and running. Not today.

I have been working on this new functionality for about 4 days now and have not bothered to add it to source control as it is not ‘ready’. So if I do not try and solve the problem I will lose out of 4 days of blood, sweat and most definitely tears.

It turns out that the storms that have been causing the amazing sound and light shows around here with the occasional power fluctuation were not liked by my external hard disk that is home to all of my VPCs

I have had this trouble before and I was determined to go straight to BestBuy that morning and get a UPC. I didn’t and it was just a matter of time before it happened again I guess. The last time I had to spend about 4 hours persuading the hard disk it was OK and let me access the files so when it happened this morning I sighed, brewed some coffee and got ready for the fight.

It turns out that good ol’ chkdsk saved the day and I am back in. All the files *seem* file but time will tell I guess.

I am going to buy a UPS this time. Honest.

Perforce is a great product. It is fast, easy to use and has some neat tools for managing the editing cycle of source code etc. We have multiple sites for development and having a fast synchronization no matter where you are is very important and perforce does a great job of this. The differencing tools are great and check-in, check-out and revert of code is simple and intuitive.

That said, ‘free’ compared to $800 a client is not to be ignored and we decided to try out SVN. Configuration is a simple unless you want to use HTTPS (which everyone does) and then you have to trawl the knowledge base articles and use some magic to get it all to work. One the server is running though getting client online is a breeze.

TortoiseSVN for simple file management and AnkhSVN for Visual Studio integration are a must as far as I am concerned and once again they are free. TortoiseSVN in particular with it’s Windows Explorer integration and differencing tools is the best interface I have seen in a long time for source control. Perforce tries to have a Windows Explorer interface but it does not do well and certainly get’s no-where near TortoiseSVN.

One major factor that attracted me to SVN is the fact that you can do what you like to the source tree when offline. The concept of checking out for edit in a pain in my line of work where I spend the majority of my time on client sites. Having the ability to make code changes during the day and check them in at night is great.

I frequently do not have to do that though as more and more clients are providing WiFi connectivity outwith their firewall to the Internet and since we have the HTTPS version of SVN running I can simple check code in over the Web without even using VPN! We previously used secure tunnel for this and the client always flaked out at the worst times  

One of the benefits of SVN when using Apache is the WebDav. This allows us to include our documents, project plans etc. in the same versioned repository as the source code but with a fit-for-purpose way in Microsoft Office of getting access to and updating the files. This is something that we have not taken full advantage of as yet but will be starting in the very near future.

All in all I would say that SVN is well worth the effort it takes to setup the server and — touch wood — the database has been extremely stable and we have had not problems.

I know that this is a very generic conversation but I will get more in-depth about the branching capabilities (used all the time by us) and how easily it slots into CruiseControl.NET in a different post.