Continuous Integration Checklist
February 26, 2006
See the Pre-launch checklist.
To start with, check in at least twice per day. That's the "continuous" part. When you're good at it, you'll check in every hour or two.
Before getting the latest code from revision control, check to see if anybody has the rubber chicken. If someone does, wait for them to finish checking in.
When you check in, follow these steps:
Run the build/test script locally and make sure it passes 100%.
Get the rubber chicken from its resting place. If it's not there, find the person who has it and annoy them until they're done with their check-in.
Get the latest code from the repository and run the build script again just in case. If it doesn't pass, you know that there's some integration problem with the code you just got. Bitch and moan, put the chicken back, and get the person who last checked-in to help you out. Start over when you're ready.
Check in your code.
Walk over to the crappy build computer, get the latest code from the repository, and run the build script again. If it doesn't pass, revert (undo) your check-in. You installed some new software, or modified an environment variable, or set a registry setting, or forgot to add a file to the repository, or something. Anyway, you need to fix the problem on your computer and try again. You can hang on to the chicken for a moment, but give it back (and start over) if anybody needs it.
Ring the bell. (Everyone else, that's your cue to applaud, or otherwise rejoice. "Yaaay.") Put the chicken back. You're done.
By the way, when step E fails, you'll be tempted to just fix the problem directly on the build machine. But if you do that, the next poor slob to get the latest code won't be able to build.
Last, but not least: Keep your build times under ten minutes. Less than five minutes is even better. If they get too long, this process will stop being a pleasant mid-morning/afternoon break and start being a real pain in the keister. Fast build times are Good For You in general, anyway, because slow builds often mean flaws in your testing approach.