SCM rules

SCM (Software Configuration Management) tools are considered a cornerstone for every good software production environment today. Despite that a lot of problems can be introduced: branches messing, lack of policies and purposes.

In his excellent paper Henrik Kniberg show us some simple rules in order to avoid main problems. Here I don’t want to just repeat the rules, rather I’d like to show how important, appropiate and useful are simple rules.

We have some goals: (1) we want to fail fast so code conflicts and integration problem pops up near the event that caused them; (2) there should be always something releasable (within a good definition of “done”); (3) rules and this “mini process” must be simple, so team(s) can’t avoid them.

Rule: each branch in SCM repository has an owner and a policy.

The owner unsures the policy is applied and the branch is coherent with its purpose. The policy describes what kind of code goes in the branch. That forces also to avoid braches proliferation without any meaning: need a branch? Ok, but what is the purpose, the policy, the owner?

Trunk is the Done branch (can release at any time)

Rule: whoever touch the Trunk is responbile that everything works well (previous functionalities included!)

Development branch: code compiles without errors, all unit test passes, builds happean successfully

This ensure in this branch only tested code is allowed: simple and clean. This forces also to synchronize often with the Trunk in order to lately discover that we have to recode something (interfaces change, new classes, …).