Read on Twitter
Pull requests add overhead to cope with low-trust situations, e.g. to allow people you don't know to offer contributions to your project.
Imposing pull requests on devs in your own team is like making your family go through an airport security checkpoint to enter your home.
Imposing pull requests on devs in your own team is like making your family go through an airport security checkpoint to enter your home.
I get that PRs are a way to make sure you get a second pair of eyes on your code, which is a good thing. But a few points:
1. PRs are not the only way to get feedback on your commits. Pairing is not the only alternative to PRs.
1/8
1. PRs are not the only way to get feedback on your commits. Pairing is not the only alternative to PRs.
1/8
2. Until your commit is merged with everyone else's work, your code is not in a potentially deployable state.
3. So PRs delay feedback on whether your code will pass tests once it is merged and made ready for deployment.
2/8
3. So PRs delay feedback on whether your code will pass tests once it is merged and made ready for deployment.
2/8
4. PRs also create extra work to make sure the code is deployable after merging. (Would you set up your pipeline to push straight to production, without additional testing, immediately on merging your PR?)
3/9
3/9
5. Automatically deploying and testing merged code is immediate feedback that proves your code is ready for deployment. You can get to this point on every commit, without interrupting anyone else.
4/9
4/9
6. This means you're not wasting anyone's time having them review code that might not work when merged and made deployable.
5/9
5/9
7. Two alternatives: have people review code as you write it (pairing), or
8. Have people review code after it's merged and passes tests (i.e. deployable). Make this a pipeline stage if needed.
6/9
8. Have people review code after it's merged and passes tests (i.e. deployable). Make this a pipeline stage if needed.
6/9
9. The point is, use automation to make sure every commit is immediately assembled into a potentially deployable state (which means merged with everyone else's work), and deploy and test it, before asking someone to interrupt their work to look at your code.
7/9
7/9
This list is pretty much the definition of Continuous Integration (CI) and Continuous Delivery (CD).
8/9
8/9
Pull requests are an alternative to CI and CD, and that's fine if it works for you. But it's not the only way to work, IMO is not designed for high-functioning teams (and there is research that backs this up, cf. https://cloudplatformonline.com/2018-state-of-devops.html)
9/9
9/9
