Fighting The Hydra: Precognitive Build Servers

Quick Link to Precognitive Build Servers, by Michael Feathers. If you’re a Software Developer (whether that’s your job title or not ;), it’s worth reading – and grokking for a while.

There’s an implicit problem in automated test execution in a build pipeline: the number of tests keeps increasing. […] the duration of a build is going to keep increasing. […] Build performance tuning has become a part of daily life on many development teams, and there are many options. […] We can use prior experience to maximize the speed of feedback that we get from a build. Kent Beck experimented in this area years ago with his JUnitMax project. […] I’ve been experimenting with a variation of that: build a map of test failures to files which were modified in the commit where the failures occurred. Then, on every new commit, take the set-union of the set of tests that have ever failed when the files in the commit have been touched along with the set of all tests recently introduced, and run them as the build. My theory (which I have not been able to verify yet) is that for many projects this process may converge in such a way that nearly all of the failures that occur for a full build will occur for this abbreviated build. […] If it works, you essentially have a build which foretells failures in the future based on failures in the past: a precognitive build.

Cool, isn’t it?