The corollary being that, if your build takes so long that you feel you have to leave the office before it finishes, thou shalt bring that up as an impediment.

Agreed in full, to the point of long-since having been codified in all of my team's revision control processes.

Just to add to Laribee's Final Rule of Continuous Integration about never going home with a broken

Just to add to Laribee's Final Rule of Continuous Integration about never going home with a broken

Just to add to Laribee's Final Rule of Continuous Integration about never going home with a broken

Or, perhaps you could change the rule to be: thou shalt use TeamCity to get a pre-tested commit so you'll never commit anything that breaks the build.  Thou shalt realize that TeamCity is free for most projects, so you really have no excuse... :)

Can we apply the death penalty to this?  OK maybe that is harsh, but this is a great law.

Pingback from  Dew Drop - September 23, 2008 | Alvin Ashcraft's Morning Dew

This seems (as does Jeremy's) lower-level than Continuous Integration; this is a law of basic team development.  A dev should be, within reason, integrating their changes on their local machine to ensure what they will check-in will build. The follow-up is, of course, to stick around to make sure between that compile and the check-in a conflict doesn't break the CI build.

If there isn't a general policy or practice to try to integrate all changes before a check in, it's really hard to mandate a policy or practice to stick around to validate the CI build.

Just give them the broken build token: ferventcoder.com/.../continuous-integration-enhancement--the-broken-build-token.aspx

Pingback from  Jeremy’s Penultimate Law of Continuous Integration - taccato! trend tracker, cool hunting, new business ideas

Podcast #4 - Continuous Integration and FireBug

Breaking the nightly build is what has long counted as a sin for those who have done this basic form of CI for decades. It has nothing to do with what's on your local machine. Just don't break the golden build. Of course, it's easier with SVN, CVS, Perforce, ClearCase, MS Team....

BTW, nice article on DDD in MSDN except that part about "not needing an IoC container". True, we don't need IDEs or a fancy symbolic debuggers. However, the impact of IoC containers on Separation of Concerns has been remarkable (to say the least) as evidenced by Spring and Seam. That you don't need one is a sour grapes argument, that is to say not a meaningful point.

No worries, like MVC, MS will eventually start pushing a pale copy of this decades old technology, without mentioning, or recognizing, those who pioneered and perfected it.

Active Record

There's an article on Active Record, too. The antithesis of separation of concerns. A real laughter to be sure. Doesn't exist in, say, Seam, because IoC eliminates that abortion.

Podcast #4 - Continuous Integration and FireBug

zgZAkW