Break, Then Leave and Pre-Check In Checklist

Originally published 16 Sep 2006

My build/SCM blog series (see part 1 and part 2) ends with a look at one of the most annoying things a member can do to his team and a checklist to follow for reducing the chances of breaking a build.

So what can really irritate the rest of team? How about checking in a bunch of changes that break the build and then leaving for the day? This is bad enough for small teams, but consider bigger, distributed teams developing complex applications. You could have team members who start their day after you've left. If the team follows the rule of not checking in on a broken build, what's the team supposed to do? Well, to continue progress, somebody else has to step in and fix the build. This can really slow a team down.

A good practice is to wait for a successful build after your last check in before leaving. After all, you know the most about the changes that would have broken the build. This practice implies some prerequisites: a continuous integration system that runs often and builds that run quickly.

Now that I've ranted enough, what can you do to reduce the chances of breaking a build in the first place? Listed below are steps to follow. It starts at the point where you're ready to check in. Essentially, you mimic the continuous integration system on your development workstation.

1. Update your view so you have the latest versions of all the files.
2. If you use configuration management software that allows hijacking and reserving files (like Rational ClearCase), now is the time to "unhijack" and reserve existing files with changes. By existing files, I mean files the CM software knows about (not new). You only need to reserve files if your team follows that practice. If nobody on the team reserves files, then skip this part, but it's important to reserve at this point if your team follows this practice to ensure all of your changes can get checked in.
3. If necessary, merge any existing files that have been updated and checked in by others since you checked out. You want your files to represent what will be checked in. Now, your files will contain your changes merged with the most recently checked in versions.
4. Make note of any new files that need to be added to source control and any deleted files that must be removed from source control. Forgetting to do this can cause a build failure.
5. Run the application to make sure your changes function and integrate well.
6. Do a clean build, compile and run all the unit tests. Consider a single ant target that does this for you.
7. Check in. Don't forget those new and deleted files!

Do I follow all of these steps on every check in? No way. That wouldn't be practical. You need to consider the size and impact of your changes. The bigger they are, the more rigorous you should be. If I made just a small change, I would probably just make sure the code compiled and unit tests for that change passed.

Well, that's it. Hope you enjoyed.