Creating Builds

This is the second post discussing creating an automated build structure.  After selecting CC.NET for our build infrastructure due to cost, stability and personal knowledge, I need to determine which builds I am going to create to begin the process of having a more streamlined build process.  While Continuous Integration hardliners may not agree, I created two builds: a Commit Build and a Release build.

Commit Build:

The commit build is executed every time a developer checks into source control for the project.  The purpose of this build is to ensure that the check-in compiles and any automated tests execute successfully.  This build should run in less than five minutes so the developer can retrieve feedback from their check in as soon as possible.  The build rebuilds the solution using the debug configuration, updates the assembly version with a debug assembly version but, does not copy assemblies to a directory for consumption.  Therefore, the output of the commit build will never be used and this build is only used for commit verification.

Release Build:

The release build is executed each evening at 11:30 PM as well as on demand by anyone on the team.  The purpose of this build is to create a output which will be tested and potentially released by the team.  While this build should run under 10 minutes there is less of a time constraint on this build except for the fact that, if this is running during the day, developers should not check in while it is retrieving the source to limit the chances of the build pulling half a check.  The release build builds in release mode, updates the assembly version with the the build number, copies the output to a share drive and obfuscates the code.  Ideally, the release build will also build the installer, but to do this the installer would need to support build to build migration instead of merely release to release migration which it does now.  Therefore, the output is a releasable.

As I stated above some may cringe that I have created two builds and believe every check in should create a testable or releasable output.  The reason I did not go down this path was due to the excess of builds.  Copying each commit build to a server which is backed up will clutter our server with builds which will never be used.  While storage is cheap, there is no reason to waste it with unused output.  Instead, achieve the benefits of near instant feedback with a Commit Build and enable the team to create releasable builds in an ad-hoc fashion with a Release Build.

My team supports many different applications and as we move forward we will be creating a Commit and Release build for each supported branch of each supported application.

In the next post on this subject I am going to discuss how I structured my NANT builds to share properties and targets and decrease modifications to the ccnet.config file.

Creating a Build Infrastructure

Over the past couple of days, I have heard the following:

• “Hey development, can I get a new build?”
• “QA failed a bug fix, but we determined the wrong build was installed”

These two statements are symptoms of having either a poor or non-existent continuous build process.  In my case it is non-existent so I am working on creating a build infrastructure from the ground up.  I am going to research build software, determine the right builds to execute and work with the team to educate them on the build process.

Creating a build process does not happen over night and it will change over time.  Therefore, this will be a series of posts as I work on it.

I am using Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation as a guide during this process.  I have been very impressed with this book as it is easy to read, gives insights into best practices and provides a lofty goal for my build and deployment process.

So, the first step in this process is to create stop gap builds and in order to do that I need to choose the CI software which will run the builds.  I have used CruiseControl.NET before but, it was recommended to me that I look into Jenkins which seems to be the next generation of open source CI software.  After installing it  and taking it for a test run, I came away with some pros and cons:

PROS:

The main pro for Jenkins is that it removes the necessity to write NANT in order to make the build work, it allows you to select build activities via drop down and plug ins.  Further, Jenkins has a plethora of plug ins which could be used for any number of build activities.

CONS:

While I am sure that Jenkins is running the build infrastructure for many companies, in my short evaluation, I could not get my build to work without using a .bat script the developers created to build the software manually.  The only build activity I was using was the “run .bat file” activity so I was not taking advantage of Jenkins major pro.  Through my research I found numerous critical and high bugs within their bug tracking system which were a bit dated.  Now, this is open source and free so I don’t have any expectations of grandure but, since I am not a full time build coordinator I don’t want to continue to beat my head against the wall trying to figure out why something does not work.

So, given my past experience with CruiseControl.NET and the fact that it has been well tested and used throughout the industry, I decided to install CC.NET and start creating the build infrastructure with CC.NET.

Now that I have the technology, I need to start creating the builds.  In the next post I will discuss the builds I am creating.