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.