Tuesday, April 08, 2008

Automation for the people: Continuous Integration anti-patterns

How to branch codeImage by Phillie Casablanca via FlickrAutomation for the people: Continuous Integration anti-patterns discusses some interesting no-no's in software development team practice.

Today I ran into one, namely 'infrequent check-ins' but it was hidden under a pile of branching/merging confusion.

I was discussing branching and merging strategies for the development teams with one of the team members. He explained how work was done for some time, apparently to his satisfaction. A project team would branch off a release branch at the point when a release was going in acceptance test. The team would work on that, fixing issues, and would never merge back into the trunk, except for some cherry-picked bugs.

So far, I don't object to this way of working, but I introduced the idea of personal branches, or an alternative, feature branches, where developers would create branches for every feature, work on that and then merge it back into the stream of the release where that feature belonged in. Wholesale merges, in other words.

This was out of the question. Merges were supposed to be controlled, high exception operations performed under high levels of scrutiny.

This encourages infrequent check-ins: it prevents developers from doing frequent check-ins while working on their own corner of the project. A developer shouldn't only check in when they want to add a major feature; Ideally one should check in after every few lines of code which prove ok. However if one pollutes the main source tree with every little commit, then, yes, this is impractical.

The solution however is not to delay or generally discourage merges. One should setup branching policy so that developers can check-in however often they want without bothering the main line.

Conclusion

Sometimes it takes some time to discover a bad practice in disguise. The no-no of 'Infrequent Checkins', and all the other anti-patterns too, can be disguised in many ways of 'practice' which seems perfectly reasonable by itself. Until you fully work through the consequences.

Btw, don't forget to read part 2 of the anti-patterns article.

Creative Commons License

Unless otherwise expressly stated, all original material of whatever nature created by razor_nl and included in the 'How We Work' weblog and any related pages, including the weblog's archives, is licensed under a Creative Commons License.