| It isn't just that the tests need to be good and humans break things sometimes. At a certain scale, the following happens enough to be a problem: - changeset A is submitted, an integration branch is cut from latest master, and CI begins - changeset B is submitted, an integration branch is cut from latest master, and CI begins - changeset A's integration branch passes CI build/test, so A is merged into master - changeset B's integration branch passes CI build/test, so B is merged into master - however, changeset A + B interact in such a way that causes build and/or tests to fail - build is now broken You're probably thinking "that sounds like it wouldn't happen very often. Both changes would need to be submitted within some window such that changeset B's integration branch does not include changeset A, and vice-versa". Which is correct, but that's where the scale comes in. With enough engineers this starts happening more, and the more engineers you have the more unacceptable it is to have the build broken for any amount of time. And the more engineers the more code you have so the longer any individual build starts taking which lengthens the window during which the two conflicting changes could be submitted. You need to do it in a way that serializes the changes because that's the only way to prevent this, but that takes too long. So the paper is about how to solve this problem. |