The question came up via Buddy Lindsey: "on a beginner's level, why should one use a Continuous Integration solution?"

Here is my honest, un-googled, from-real-world-experience answer as someone who has done non-trivial corporate team-based development both with and without CI.  All of this applies equally to web and desktop development, from a mechanical standpoint there's absolutely no difference.  The differences are in the code.

Preamble

If you are alone, writing code with no team, no release cycle, no QA, or anything of the sort of stuff that represents professional software development, then CI is probably nothing more than mental masturbation , and a nice exercise to do that nets you no gain.

Once you start working on a team and implementing anything other than "code+deploy=profit" as a methodology, then CI becomes more important.

At root, CI is a tool to automate build and build-related tasks.  A typical scenario is some CI "server" that checks the source repository for changes, gets latest, makes a build, and reports success/failure.  If you are running automated tests, CI would run them for you with the build, and would include the output in its report.  If you are running code metrics or static analysis like NDepend, FxCop, and so forth, CI would run those for you post-build and include the output in the report.  Finally, you could configure your CI process to deploy newly-built code to some location, possibly for QA purposes.

So let's take a scenario where you are on a team working on an asp.net website.  You are implementing features and bug fixes from the backlog/list. 

Scenario 1 - Team Development, No Continuous Integration:

Each programmer does his own thing, checks in...whenever, typically before leaving for the day, then bails.  Someone gets latest, build dies, and their work is fucked until the other programmer comes back and fixes his stuff. 

Further, somebody has to push the changes to the test environment (assuming you are developing locally, please do that) and notify QA or whomever that there is changes to the system.  On larger projects this could end up being a quite lengthy process.

Further, if you are doing the testing/code analysis stuff, you want to run that at some point.  It's a pain in the ass to do it yourself every build, so you do it...whenever you get to it, because you are also writing code and pushing releases to QA, and typically it falls by the wayside.

Further, maybe dev1 checks in some changes, but dev2 for some reason doesn't get latest before he deploys to QA (or worse, live).  Dev1 made some important bug fixes that don't make it out there.  If the communication cycle between QA and dev isn't great, this could go unnoticed...forever.

Scenario 2 - Team Development, With Continuous Integration:

Each programmer does his own thing, checks in...whenever, but is encouraged to do so often.  The CI server builds in near-real-time and everyone knows if the build is broken or good.  If the build-breaker is gone for the day, you know not to get latest.

A one-time setup has been done so that each successful build is pushed to the QA site/distro point, and an email is sent to the QA team automatically on success that informs them of new versions.  Further, some systems (depending on your source control) will allow you to read checkin comments, which could (should) contain at minimum what the checked-in change was.  Or possibly using a system like TFS you can mandate that checkins be attached to a work-item.  All of this information can be consumed by CI and included in build notifications.

CI does nothing but CI and therefore is more than happy to run your unit tests, ndepend, fxcop, ncover, and whatever else you want to throw at it every time it builds.  A one-time configuration gives you all of their outputs in a nice consumable web-based report, archived per build, so that it's painless to look at and understand the quality and progression/regression of your code.  Your code and team get better as a result of being painlessly more conscious of quality.  Having CI do automatic deploy from source control eliminates the human error factors as well.

Wrap it up here Scott...

The basic idea is to always automate something that's important but tedious.  Continually building fresh code and running tests and all of that is not only nice, it makes the code and the process more transparent and more adaptable to change.  It brings the code quality and practice of writing software (the mechanical stuff) to the forefront and helps you enforce good practice without spending a ton of human time worrying about it. 

So there is your 20 foot view of CI and why it is useful.

Tags: