At Meerkats we peer review every single piece of code that is written, before it can be merged into a build. With how busy we are, that can lead to blockages that can be easily defended against.
We use Github's Pull Request system extensively for our code reviews. All code written in the agency is put into a new branch (we kind of use git flow) that will eventually be ready for sign off from a peer. To be reviewed a branch is pushed to Github and a new PR is opened with your changes and some documentation (in the form of a title and a description) to ready your code for another developer to eye over.
That developer (or a few) will go through the code, make comments and suggestions or ask a few questions about some awesome piece of code. There may be some changes required, so the original developer will write some code, push it to the same branch (which updates the PR) and ask for a follow up review. This goes in circles until it's been signed off and the branch is merged.
As we've grown it's not uncommon for us to have 20 or more reviews that need attention on any given morning. It became evident that we were going to need some sort of system to keep track of each PR's current state to ensure we're not wasting time on reviewed code or missing a crucial bug fixe in our builds because it was missed in review.
So we started using labels. We don't use Github for issue tracking so the defaults were sitting there not being used for anything in particular. Our initial requirements were easy:
The last person to touch a PR (either the developer after they push some code or a reviewer after a comment) is responsible for updating the PR's labels to ensure that the state is clear. Now when I sip my coffee in the morning I can see a long list of all our outstanding code and know immediately which need my attention as a developer or as a reviewer.
This was working great, except for that our set of labels was not in sync with the default set that Github provide. Every time we open a new project (this happens very often in a digital agency) someone (me) is forced to manually replace all the default labels with our own set ensuring consistent colors. This was a major slog each time (especially as our labels have grown) so I got fed up and wrote a command line tool for this.
It's command line program written in
golang (my first attempt!) that allows anyone with access to a repo (via a token) to easily add and remove labels from a repo when initialising a project. So any time I open up a new project I need only run two commands and we are ready to roll.
$ labels remove jimmyhillis/labels $ labels add jimmyhillis/labels ready-for-review:fbca04 awaiting-followup:bfd4f2 shipit:207de5
It's very much a work in progress and I'm already planing some improvements to the tool which hook into
hub to help automate setting the state of a PR after important actions.