Apr 26 2013
If automated testing is a part of your process, you know how much it hurts when tests fail on your master branch. Every red test on master makes it more likely that further breakages will sneak in, for several reasons:
How best to keep the master branch green? You could attempt to foster an organizational appreciation that breaking master is a Very Bad Thing, in the hopes that this will make it happen less often. Some folks take this to interesting extremes, including ritual humiliation (however tongue in cheek).
(source: http://www.flickr.com/photos/foca/6935569551/)
While this approach may encourage people to care about the integrity of the tests, it has some limitations:
Another approach is to enhance the role of your continuous integration server. At MojoTech, we don’t just monitor the mainline development branch with continuous integration; we run the entire test suite whenever anyone pushes to a remote branch. Therefore, there is no shame in seeing a feature branch break the tests; in fact, it’s expected.
The other side of the coin is the following policy: “Don’t submit a pull request until you can see that the tests pass on your branch!” This makes it really easy to ensure that the test suite is ALWAYS passing on your master branch; nothing gets merged unless you already know that it won’t break tests. (Of course, there’s always the possibility that tests could be passing in both the mainline branch and in the feature branch, but that merging one into the other could cause breakages, but this is a comparatively rare occurrence).
This makes the maintainer’s job easier, in that it eliminates a type of code review which would otherwise prove common and repetitive: “This change breaks some tests. Please adjust.”
One tool that facilitates this approach is Semaphore.
I’ll follow up later with more details about how we make Semaphore work for us.
—Matthew Forsyth