How We Optimized Code Review with Gitpup

Earlier this month, we introduced you to Gitpup, the code review assistant we’ve created to keep our dev team on task, on point and on each other’s good sides. For us, implementing Gitpup has optimized the code review process, resolving the issues we’d had with our previous process. Here’s a look at before and after Gitpup.

Before Gitpup

Like you, we take code quality seriously — we need to be sure that every change to our repositories is peer-reviewed before it’s merged into a project’s mainline. Prior to Gitpup, we used the GitHub Flow Model for our code review process, which was a great way to ensure that multiple team members viewed potential changes and were able to to call out logical, typographical or formatting errors long before they have a chance to make it into a production system. However, as more and more projects entered the pipeline, managing this process became increasingly difficult.

It involved the following steps:

1. create a pull request (PR),
2. copy the PR link into a designated chat room,
3. have someone assign themselves the PR — someone who would then possibly re-assign the request for different aspects of changes (For instance, SASS changes might go to the front-end people, whereas the PHP work would be inspected by a developer on the back-end)
4. Then mark the approved PR with a specific emoji as a way to say to the team that it was complete and ready for merging.

It was getting the job done, but it also left us with a lot of questions: Who’s assigned to what PRs? What’s open? What’s been approved? Has this request been looked at, and by the right person? We would naturally ask our questions in the code review chat room … but we wondered, why not automate the answers with a robot? So we built Gitpup.

Code Review with Gitpup

Gitpup, fetch me a PR!

With Gitpup, the idea is that a small-ish team like ours (fewer than 25 developers) can swap pull requests in a central chat room (we use Slack), and – leveraging our knowledge of our own and each other’s strengths – make sure each request is assigned to the right person. The entire team is looking at Slack all day anyway, so advertising pull requests there guarantees they are never lost or forgotten.

Gitpup coordinates this process, making it insanely simple. When a pull request is opened, Gitpup—we named ours Felix—announces the request in our #code-review chat room along with a review number that can then be grabbed by the right person:

Easy, right? You can see here that the team knows the pull request was opened, and that Nichole grabbed it for review (because she is another front-end developer who knows this change is in her area of expertise). She takes a look at it, and for this particular request, blesses it easily:

Note that Nichole didn’t have to actually add the approved label in the GitHub interface, she only had to state /approved in her review comment, and then Gitpup did the work of adding the approved label to the pull request on her behalf.

This PR is now ready to be merged:

And, look at that. Another one bites the dust! Both Nichole and John get to revel in their newly earned, delicious Karma. John gets one Karma for opening the request, and Nichole gets five for the review — as it should be! After all, she’s doing the hard work here.

Good thing Nichole’s a generous spirit. Now, she can show she cares by spreading Karma love back to the team.

If you think Gitpup can improve your team’s code review process, we invite you to get a Gitpup of your own.