Jeremy’s Other Laws of Continuous Integration

Since the first one inevitably irritated people, let’s go for rule #2 & #3:

2.) Check in as often as you come to a stopping point.  The more frequently you check in, the less troubling your merge conflicts will be.  For the most part, I think you can make merge conflicts almost entirely go away after the first couple weeks of the project.  We had a mild conflict today (that spawned my tongue in cheek remark about checking in first) that was caused by one pair renaming a testing utility method to make it more consistent with our other testing methods, while my pair was still using the existing method name.  Both pairs knew it was coming so it was no harm, no foul

3.) Communicate with your team members anytime you think you might be doing something that would cause a merge conflict.  Yet one more reason why a colocated team beats a distributed team

4.) Find ways to divide your work into smaller chunks.  If you can’t check in new code for days at a time because you aren’t at a clean point, you may have some serious problems with your design.

5.) If you can’t check in your code for a long time ( > 1/2 a day let’s say), be sure to update your version of the source code with the updates from the rest of the team to make your eventual checkin easier

6.) Rotate your build notification sounds.

7.) And in the “do as I say not as I do” category, you might learn how to use a merging tool (then come teach me).

 

And yes, you can solve the merge conflict problem by going to a pessimistic locking strategy, but I think that causes much more friction than the occasional merge conflict.

 

 

…and some other boring things like making sure the build actually succeeds, fixing broken builds immediately, and making sure that the build sets up the development environment and other details you can find in the Check In Dance.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.hadihariri.com/blogengine Hadi Hariri

    @Jeremy

    Use BeyondCompare. It’s not a “merge” tool, it’s a diff tool, but that is the entire beauty of it. It makes merges so easy.

  • http://sharpbites.blogspot.com alberto

    Even for just support releases you’ll find the very same problems when you merge bugfixes into trunk.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @alberto,

    I wouldn’t say that branching is completely unavoidable, but I’ve never seen a real refactoring that I couldn’t do in the trunk. The only thing I branch for is support releases and experimental spikes.

  • http://sharpbites.blogspot.com alberto

    It’s not a problem of lack of comunication, it’s a problem with the tool. Knowing the problem beforehand doesn’t fix it, just blocks you. It’s not a very big problem when all you are changing is a file, but it’s much harder when you make a branch to make significant refactorings (or is it unrealistic to do such things in a branch?)

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @alberto,

    See #3:

    3.) Communicate with your team members anytime you think you might be doing something that would cause a merge conflict. Yet one more reason why a colocated team beats a distributed team

  • http://sharpbites.blogspot.com alberto

    I am not talking about that. I am talking about the conflicts and problems at commit time when someone moves/renames a file (svn move, not explorer) and someone else changes it.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @alberto,

    Just use VisualSVN. The old rename file problem from the Ankh days completely goes away.

  • http://sharpbites.blogspot.com alberto

    Just in case it was not very clear from my comment in your last post, it was not about CI, but about SVN. It sucks badly both at managing renamed files (which is especially relevant when merging), but it seems like it is not an issue for anyone.

  • http://computeristsolutions.com josh

    winmerge (http://winmerge.org/) I’ve tried others but keep going back to this; prolly partly because its also free/oss.

  • Jeremy Gray

    :D