Also plan for a hotfix to production path in cases where a commit is non-revertible (e.g. one-way migration) and a confident fix is available but time waiting for CI may not be. Or better yet, always make your tests run in a minute or two.
What we used at my previous startup was a CI pipeline per microservice with stages for build/test, staging test/deploy of service, journey test in staging fully deployed, prod test/deploy of service, and journey test in prod fully deployed.
A journey test is the top 10 or so things that a user should be able to do (e.g. sign-up, do a primary thing, do another core thing, get a notification, tell a friend to sign-up). No matter how bad a deploy is, if the journey test passes, at least you know that's it's not that bad, or if it fails you know it right away. One downside is that it runs after deployment so it's a live issue. (Checking pre-deploy is a false sense of security.)
By this, do you mean that trunk-based development with pairing has a higher rate of shipping defects to production than other approaches?
If so -- what's the upside of this approach?
Or just continuous delivery?
They are not the same thing.
If you want real continuous deployment (which you should):
- you need feature flags. See something like LaunchDarkly.com
- you need Trunk Based Development. This means no branches. Or rather, only branches that live less than one business day.