Simplifying DevOps #1: Pull Request Pain

We are starting a series of posts about how to make the work of delivering software less painful. This first post is from Bryan Finster, who has a long history of trying to reduce the pain in his daily work.

I've been developing enterprise solutions since 1997. Most of that time, the work has been painful. I've made the work less painful everywhere I've gone because I'd rather focus on solving problems for the end users than solve the problems of how to solve the problems. Continuous delivery was a real eye-opener for me when I first learned how to do it because it forced us to remove so much pain to achieve daily delivery that the work became joyful. I want that for everyone.

So, why is this blog called "Simplifying DevOps?" Because DevOps isn't a job, it's how we do the job. It's about removing waste from everything around us so we can deliver better value.?

Tip #1: Pull Requests

Pull requests may be a necessary evil when working in regulated environments because they can provide an audit trail to show that more than one person was involved with every change. But PRs are among the most common causes of delivery pain because they add wait times and handoffs. Mitigating this requires teamwork. Here are some ways to reduce that pain.

Pull Request Workflows:

• Best:? Pair program on a branch and have the driver raise a PR that the navigator approves and merges.
• Good: Raise a PR, find a friend, and pair on the code review. Resolve as many issues as possible in real time and merge the branch. If a change takes more time than that, pair again later.
• Meh: Raise a PR, and alert people that code needs reviewing. If you review asynchronously and leave comments, alert the other person that comments need addressing.

No matter which of those flows you use, these following small improvements will further reduce pain:

• Whoever approves the PR should merge the branch. This prevents any branch from getting outdated.
• Configure repositories to automatically delete branches when merged. They have no value after that.
• If working on a team, aim for a CI workflow where very small changes are integrated at least daily. "Feature complete" is not the goal. Sharing non-breaking code with the team that is eventually feature-complete is the goal.
• If contributing to another team's product, keep changes small and cohesive.?
• Never refactor and enhance functionality in the same change.
• Default to squash/merge to make it easier to identify changes later
• Optional: Open a PR as a draft as soon as you create a branch to give people an early view of what's changing.?

Want more suggestions like these? Let us know!