- Posted by Justin on September 29, 2008
Good laws of continuous integration from Jeremy Miller. The first law is pretty funny but oh so true.
Taken from: Jeremy's Other Laws of Continuous Integration
1.) If you check in very often and/or first, you can make merge conflicts be someone else's problem
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).