[dantiberian]

> If you insist on no errors on master ever you will kill throughput.

There are a large number of automated tools which will help you prevent merging code that could break master: https://github.com/chdsbd/kodiak#prior-art--alternatives. The basic approach is to make a new branch from master, apply one or more commits on top of that branch, run the tests, and if tests pass, merge those commits (with fast-forward) back onto master. This makes it very difficult to get broken commits on master, as they have to pass the tests before. It is possible if you have a flaky test suite, but in my experience it happens very rarely, and is usually very easy to fix if something creeps in. In my experience, they speed up throughput, not slow it down, especially when you account for the disruption that merging broken code to master can be.

https://graydon2.dreamwidth.org/1597.html has a good discussion of this:

The Not Rocket Science Rule Of Software Engineering:

automatically maintain a repository of code that always passes all the tests

[sytse]

The problem with a popular repository can be that running the tests can take longer than the time you have between merges.

In GitLab we made merge trains https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipeli... to solve this problem automatically.

With merge trains the merge requests with a passing feature branch is placed in a queue and tests are run against the combination of that branch and all the branches before it merged in. Since tests will pass 95%+ of the time the feature branches passes this can speed up the amount of merges you can get into master by 10x or more.

[dionian]

automated tests don't necessarily catch all errors