“Familiarize Yourself with Continuous Integration” has been pushed to the bottom of my tasklist for the better part of two years now.  As a result, the closest I’ve come to continuous integration is “getting the latest” and hitting F5 about 1000 times in a given day.  I have dabbled with test driven development, but otherwise, I am completely ignorant when it comes to this stuff.  Sure, I understand it conceptually, but putting it into practice is a different story.   

Quite often I will receive a friendly reminder letting me know that I really need to get going on this.  The most recent reminder came in the form of Jeffrey Palermo’s post, which I read last week, and made me eager to start digging in.  No excuses, right?  Palermo wrote “A very popular CI combination of tools is CruiseControl.Net for the build server (build reports, stats, and notifications), NAnt (an xml notation for the build script itself), NUnit (for automated tests that run as part of the build), and the code compiler.”  I took this as my starting point and immediately downloaded CruiseControl.Net.  I read through a good chunk of documentation and then … I dropped the ball.  Again.  But then, a couple of nights ago, I received a request to review FinalBuilder - another continuous integration solution.  It is funny how the universe works.  I think it is about time I get that two year old task off of my list.

FinalBuilder is an automated build and release management solution for Windows software developers and SCM professionals.  One may use FinalBuilder to define, debug, maintain, run and schedule reliable and repeatable build processes.

I spent an hour with the tool the other evening and I was pleased from the get-go.  Since I’m a newbie, I appreciated FinalBuilder’s approach.  For the most part, they assume nothing.  The web site does a fine job explaining continuous integration and on the initial launch of the application, a configuration wizard let me choose the version control systems, compiler actions, help compilers, installers and licensing tools I wanted to make available.   I felt like I was being led down a path, so to speak.  Anyway, the list of Version Control Systems alone will give you an idea of the number of products which integrate with FinalBuilder. 

I opted to go with the bare minimum and selected the following: SubVersion for version control and Microsoft Visual Studio .NET of my compiler. 

To be honest, I didn’t know what to do after the configuration wizard was complete, but I solicited the support of the tutorial.  My wizard-guided walk in the park was over.  I reviewed the provided examples and the took a product tour, a then I was, well, still clueless.  I jumped to conclusions and assumed that one needed to have more of an idea of what continuous integration is all about to use the product.  My assumption was half true.  Though FinalBuilder doesn’t walk you through the creation of the build script — for example, you aren’t going to be prompted to create a step to pull the latest code base from the repository to you build machine – you are provided a list of “action types” which you can do with as you choose.  Ultimately, this approach works great and even I was able to figure it out after about ten minutes of playing around.  I guess I was a little surprised by the hands-off approach FinalBuilder took with the scripting building after all the handholding I received when it came to the configuration setup. 

I created a three step build script:

1. Subversion Checkout
2. MSTest Execution
3. Build .NET Solution

I played it safe and attempted to executed the script after each step added.  Murphy’s Law guarantees I would have problems — and I did. 

Before I continue, I would like to share that FinalBuilder’s build log is second to none.  When I did encounter an problem, the log brought the issue to light and let me know how/where to resolve them.  Though the build log proved to be extremely helpful, it was my crutch and I was nearly completely dependent upon it.  It was like a game of Hide the Pot and after each step the build log would tell me if I was getting warmer or colder.  Figuratively speaking, I was using FinalBuilder with my eyes closed and a hint (a single hint) was only provided after an action on my part.  Here’s what I mean:

There are details associated with each step.  In the case of the SubVersion Checkout, I provided a working folder, source and destination locations, and security information.  Fantastic.  When I executed my script and the build log generated the following error: “Subversion location has not been set, please check the location in Tools -> Options.”  Warmer.  Though the generated message helped me resolve the issue quickly, don’t you think 90% of first time users encounter this exact global-options-are-not-set condition?  I understand that most users will follow the build log’s instructions and set the binary location a single time and then they are good to go for every project script going forward, but I might suggest saving the user some time and frustration by asking for this information earlier on in the process.  Perhaps global setting instructions could be provided after the configuration wizard completes or when the first SubVersion action is added.  In either case, it may be just me, but I didn’t like the way the build log provided instruction on how to use the tool AFTER I took my best guess.  Once I provided the Subversion binary location, I tested the script again.  Colder.  There was a space in the full path of my destination folder location…which caused my script to bomb…which was uncovered when script was executed AGAIN.  Tighter form validation (or more than a single build log hint on my initial test) might have saved me some time in this case. 

I mention the next issue not in an effort to belabor the point made above.  I mention it instead because I believe it to be helpful.  I received the following error when testing the compiler action: “ASPNETCOMPILER : error ASPRUNTIME: The precompilation target directory cannot be in the same tree as the source application directory.”  I may be wrong, but I believe this is a default setting in VS 2005 and this issue may be resolved by modifying the output folder as found within the MSBuild Options on the project’s properties.

After all was said and done, my three step script was working repeatedly without any issues (and global variables were saved) within 30 minutes time.  Though I put a lot of emphasis on what FinalBuilder could do better, I found the product effective and easy to use.  FinalBuilder features over 600 built in Actions which allow you to do the following and much, much more:

• Compile applications from source code 
• Compile setup/installer programs
• Work with Version Control Systems, to get, check out, check in & label files
• Handle versioning with ease
• Create & edit INI files & Windows registry keys
• Burn CD’s & DVD’s, or create CD/DVD images (ISO images)
• Zip & unzip files and other archive formats
• Run automated testing
• FTP files to/from servers
• Send emails, post on news servers
• Handle errors, run multiple tasks in parallel, and dynamically change the build flow
• Iterate over sets of files and other lists
• Compile help files
• Schedule builds

You may read more about FinalBuilder and Continuous Integration here and you may download the fully-functional, 30-day evaluation version here.

I know I am going to move forward with Continuous Integration and FinalBuilder may help me out along the way. I’m glad I was made aware of this product when I did.  Thank you Universe.

This was a paid review.