Pull requests slow down continuous delivery when used as part of standard code changes in software development. If you make use of pull requests you should ask yourself:
- How much time are you spending waiting for pull request approvals every day?
- How confident are you that integration tests will pass when you open a pull request?
- How many times has code that doesn’t work as expected been approved?
Continuous Delivery Requires Integration Testing
When developing software we want to test and release software as frequently as possible so that we can get fast feedback and make rapid improvements.
In order for us to deliver software we need to run integration tests so that we can confirm the behaviour of the system and identify any problems.
But before that …
Integration Testing Requires Code Integration and Deployment
We need to integrate our code changes and deploy it to a test environment before we can run valid integration tests.
This process could be as simple as committing the change to the main branch and waiting for automatic deployment and testing. But for many teams this means:
- Creating a branch with a pull request.
- Messaging other team members asking for code review.
- Reviewing comments on the pull request.
- Making changes to the code.
- Repeating from step 2 until the right number of approvals are provided.
- Merging the code and waiting for deployment and testing.
How Pull Requests Get in the Way
Waiting for pull request approval of our code changes could take minutes, hours, or even days. This time directly impacts our ability to get feedback on the code changes because it occurs before our integration tests can be run.
Instead of wasting time waiting for approval of code that we haven’t fully tested, we should be aiming to get instant approval or complete the review once we have confidence in our code.
How Do We Move Faster?
There are two main options to prevent pull requests sabotaging your software development lifecycle by slowing you down.
Pair Programming
Both developers working together on the code whilst sharing a screen, keyboard, and/or computer can be used to guarantee minimal downtime between a pull request being opened and approved.
This works because both developers working together should understand the code, agree on the implementation, and be available at the same time.
Pre-Release Code Review
Completing code review after deployment and testing but before release can replace the need for pull requests. This still allows for the same level of review but gives developers the confidence and fast feedback of running integration tests first.
We can implement this code review process by adding some extra steps to our deployment pipelines.
First we need to diff the current code and new version, which can be done with git commands:
git diff e237udbas r2bghur392
Then require manual triggering of the release after reviewing the code changes.
What Do You Think?
These are just some examples of ways prevent pull requests from slowing us down when continuously delivering software.
Do you think these ideas could help improve your software development? Let me know on Twitter: @BenTorvo or via Email: ben@torvo.com.au