Seeing that DJ Miller is spinning up some amusing-but-true laws of continuous integration, I’m gonna weigh in and declare Laribee’s Final Law of Continuous Integration. I see it as so critical that I’m going to put it quasi-biblical speak and in a blockquote:
Thou shalt not leave the office before the successful build of thine last commit. Doing so is beyond uncool and shall impose as a penalty, at minimum, the collective stink eye of the team to be cast upon thee.
Or maybe we’ll go with modern and more direct version.
Stick around and make sure your last commit doesn’t break the build.
zgZAkW
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.
Just give them the broken build token: http://ferventcoder.com/archive/2008/08/20/continuous-integration-enhancement–the-broken-build-token.aspx
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.
Can we apply the death penalty to this? OK maybe that is harsh, but this is a great law.
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…
Agreed in full, to the point of long-since having been codified in all of my team’s revision control processes.
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.