Anatomy Of A Continuous Integration System Part Zero

Wikipedia puts the definition of software engineering's Continuous Integration (CI) simply as - "small pieces of effort, applied frequently", and that's pretty accurate. The various slices of what is packaged up these days as continuous integration  have been around for decades and re-invented every few years under various names and methodologies, but it's been a semi-recent branding effort to put these particular best practices together under the common name of Continuous Integration. 

Rather than be a flash-in-the-pan methodology, CI has become the underlying platform - the bedrock - that all the trendy methodologies have been built on for the last 10 years including Extreme Programming (XP), Agile, RUP, Scrum, etc. If your methodology isn't Cowboy Coding - and I mean the classic definition of cowboy coding - a lone developer or a handful of developers acting alone practicing anarchy for argument's sake: "your rules stifle me!" - I bet your methodology has most or all of the continuous integration basics at the bottom of it.

The industry book definition of CI has it defined as a handful of best practices - 

• Using a source code repository system
• Everyone gets latest (code) on a frequent basis
• Frequent commits
• Every source code commit generates a build*
• Build automation
• Build fast (and fail fast!)
• Build results should be public
• Automated unit tests in the build
• Test environment should mimic Production environment

* To many people, this is all continuous integration is. It's important, and achieving that standard (every commit being built) means you practically have to be doing half of the other CI best practices. It's a good milestone to shoot for when you are converting to CI or building a CI system from scratch, but it's not the destination. Heck, I don't think achieving every facet and aspect of CI means you've reached your destination, CI is just a means - a tool - to make your software production more efficient and productive with the end result of higher quality at every output. 

All of these best practices can be compared to and validated against the boiled-down idea of "a small iteration - a small complete effort - increases the quality of a larger effort". If these pieces of effort don't pay huge dividends by the time your project is hitting its stride, let alone its delivery date, then simply remove that practice from your playbook. CI shouldn't be stifling or handcuffing the developer - everything about it is about improving the quality of the software being engineered, this is not about a Configuration Manager or System Administrator power tripping. 

For the next few blog posts, I want to just write up some basic articles on constructing & running a CI environment for a work group or entire shop developing in .Net but isn't using TFS* (Team Foundations System), and I'll be mainly focusing on the art of the msbuild file and how your entire CI architecture can and should be seen in the way you craft your msbuild scripts. 

* Maybe you don't use TFS because you're the lone group in your company doing .Net, and you can't get the budget for a TFS farm, or maybe you are required to use source control system XYZ for regulatory purposes and TFS isn't going to happen for purely technical reasons. 

None of the other posts are going to be as wordy or philosophical as this one - I promise they will be short and straight to the point. They are also all works in progress - they are the best practices I have today - I not only can't guarantee they won't evolve in a year from now, I certainly hope they will.

-Kelly Schoenhofen