« May 2006 | Main | July 2006 »

June 21, 2006

Farros Capital Launches

My now "old" business partner/co-founder of MessageCast, Royal Farros has made some big announcements recently.

Last week, he announced that he has become the CEO of IMSI/Design (also forming the investor group that purchased the IMSI TurboCAD technology)

Today comes word that he has formed Farros Capital, which will focus on seed investment for startups. 

Good luck Royal, we'll miss you at the b0rg.

Farros/Hodson at iPrint
(Back in the day at Nasa)

Tags: , ,

Posted by davehod at 02:02 PM | Comments (1)

June 06, 2006

A Good Build

What makes a build process Good?

We're in the midst of creating a new/merged system and (fortunately) have the opportunity to design a build process from scratch (well, almost - a few aspects of the process are "mandated").

My experience with builds has always been mixed. When I worked at Visa, I designed the build system for the VisaNet Access Point, v10 (last I checked, the VAP is now known as GATT). I also introduced version control (RCS) to a product that previously had none (hard to imagine that previously 40 Dev's had no SCM, isn't it??). The build was fast and effective. At KPMG and Deluxe, I had no role in the build process. Builds at iPrint were extremely weak for the first few years; we simply didn't put any time into it. Things didn't solidify until one of our QA guys (Scott) took the initiative to create a kick-ass system he called Garfield.

Drawing on my previous experiences, I wanted to do things differently with MessageCast. Almost from the start, I set out to create a build process that was solid. The requirements, which evolved over time, were:

* Totally automated
* Every build was clean; no artifacts could remain from a previous build
* Every build had a version number in the format xx.yy.zzz (e.g. 3.1.364)
* Every file used in a build was labeled, including source, images, css, jsp
* Unit tests must be performed after compilation, and include the ability to fail the build if a unit tests fail.
* Unit test reports must be available in HTML and easily viewed
* Code coverage must be performed on the unit tests and include the ability to fail the build if the coverage is not up to par (e.g. 90% coverage for methods)
* Code coverage reports must be available in HTML and easily viewed
* Every build must generate documentation based on the markup in the source (JavaDoc, etc)
* Every build must capture data/information produced at each phase (compilation, etc).
* Every build must produce email to an alias providing information on success/failure. If a build fails, the email should contain enough detail to determine who should look at the problem.

We constantly tweaked the build and were rewarded with a solid process that served us well.

Drawing on the MessageCast experience, we want the new build to follow the same requirements (with the addition of a code analysis tool) 

Currently, our tool choices look something like this:

1. SCM - SourceDepot (Perforce), Subversion
2. Build script - nAnt, msbuild, CoreXT
3. Unit Tests - nUnit, VSTS
4. Unit Test Reports - nUnit reports
5. Code Coverage - Clover, Magellan
6. Code Analysis - FxCop

Whichever tools we choose, our new process should be significantly better than the process it is replacing.

Tags: , build, ,

Posted by davehod at 08:38 PM | Comments (1)