Hm, the section on using CI rather than pull requests seems odd. PRs can be part of CI. You can set up your pipeline to build and test the result of a PR; that is, you are testing each change as if you had pushed it to the project's mainline, but there's no potential for you to break the mainline branch in a way that hinders your team.
This is very nearly touched on in the "pipeline approvals" section:
"...you place the gate after code integration and automated tests. Doing this means that a human only spends time reviewing code that has already been proven technically correct."
That's a very good use case for a pull request with CI that builds/tests the result of the merge.
> Hm, the section on using CI rather than pull requests seems odd. PRs can be part of CI. You can set up your pipeline to build and test the result of a PR; that is, you are testing each change as if you had pushed it to the project's mainline, but there's no potential for you to break the mainline branch in a way that hinders your team.
That doesn't actually stop you from breaking mainline though, just make it significantly less likely.
Say you are developing a class Foo, and I'm adding new code that uses Foo. You decide to refactor Foo to Bar. We won't get a conflict because I'm adding new code and not touching the Foo class.
In that case we both have pull requests that build fine but that once merged, won't compile. Running pipelines on each PR reduces the breakage but it can't eliminate it, unless you only allow one PR to build then merge at a time.
I usually have two jobs on every PR: one that builds "as presented", and one that builds after an automatic integration with the parent branch. If the merge fails, you still have test feedback from the "as presented" build.
Depending on how long your builds are it doesn't even really take any extra time, if they're done in parallel
This is very nearly touched on in the "pipeline approvals" section:
"...you place the gate after code integration and automated tests. Doing this means that a human only spends time reviewing code that has already been proven technically correct."
That's a very good use case for a pull request with CI that builds/tests the result of the merge.