I am so excited and proud to announce Code Review – our take on code collaboration for private teams.
What a labor of love this has been. In March of this year we sat down and started taking a look at how Beanstalk can help teams ship better quality code. Customers have been asking us for pull requests for a while. We’ve resisted because we never felt like it was the right process for private teams. While amazing for open source, the innate concept of “please accept my changes into YOUR code” was just different from that of a team working together. On our team, nobody “owns” the Beanstalk codebase. We all work together with the mutual goal of getting you the best releases possible.
Sure, we have merge restrictions to protect the master branch from any mistaken merges, but there’s no one owner of that branch. There isn’t someone you need to consistently ask permission to pull in your changes.
All of that said, we weren’t naive to think that this has become the process teams are used to. So instead of just doing it the same way, we decided to take our time and think about what we were trying to accomplish. Why were people asking for pull requests? The answer is that teams need a way to release better quality work, and the way to do that is with a code review process that everyone can use.
So instead of designing pull requests in Beanstalk, we set out to build a complete code review process, one that would specifically answer the requirements of private teams building software for the web.
Research
We began by doing research of various code review processes. Eugene led the design effort for Code Review, so he spent a few weeks learning about how other teams perform reviews.
He looked at a ton of different software that exists out there, like RBCommons, Gerrit and Mondrian. He looked at specific workflows for big teams like Facebook and small teams with just a few developers. One of our biggest discoveries was how much teams wanted a more simple process. One that wouldn’t involve training and reading books to solve. He’ll be sharing his findings in a few weeks.
I then set off to talk to developers using other products or practices. I talked to teams using pull requests, and to teams using Beanstalk with no dedicated review process. What I wanted to understand was the bottlenecks and the end-goals. We learned a lot in these interviews about the pain of the existing process, and the work-arounds that teams have used to make existing processes work. After speaking with many people and teams, we were confident we could build a better code review process.
First release – Beta testing
After all the research, we created a spec, and Eugene got to work with Ilya. The guys spent months designing and implementing the workflow you will see today. Our goal was to get something solid out to our group of Beta testers.
We knew that while our research was solid, and our ideas were pretty good, we weren’t a great example ourselves of teams and how they collaborate. We needed more input from agencies, bigger teams, smaller teams, and just different teams in general.
After months of work, we got this out to beta testers and the feedback started pouring in. Some of the most exciting elements in Code Review came directly from customers in the Beta phase. We can’t thank our beta testers enough. They helped shape code review into the mature and proven tool it is today.
What you’ll get with Code Review
It’s impossible for me to give you a full overview of all the features and functionality without writing a super long post. So we’ll be including different parts in a series over the next few weeks. But here are the highlights:
- We want you to start reviewing your work early. Don’t wait until you’ve invested tons of time only to have to backtrack. Work together to get to the end faster and with better results.
- Trigger a review on any branch you’re working on. You can select one or more assignees, so you can have more than one set of eyes and multiple people who can approve the branch.
- Add watchers to your review. This can be anyone you want to keep in the loop that won’t actually be approving your code. Think of it as a way to keep your project manager up to date. Or your client.
- You have the option of having Beanstalk merge your branch automatically after you’ve completed a review. This step is not required though.
- You can also review individual commits in your repo. So, let’s say you make changes to Master and want to review them weekly, you can do that now. When you look at each commit in Beanstalk, you’ll see an approve button at the bottom.
- There is a dedicated Code Review settings section, allowing you to customize and control your process. You can require specific people to be assigned to each review, for example. Together with branch-level permissions, you’ll have full control over what happens in your repository.
- We heard loud and clear that you want to keep email noise to a minimum. All Code Review notifications are grouped in digest-like emails. We’ll wait a few minutes and send you a single email when someone comments on many lines of code, instead of many emails for each line of code. In addition, only those involved in the code review will be notified.
Resources to learn more
The power of Code Review is in the review process. Ilya has written an awesome illustrated guide based on our suggestions and best practices on how to perform a code review on your team. Give it a read and let us know what you think!
We also prepared a collection of help articles and a screencast that will help you understand how the Code Review user interface works.
We’ll be back soon to talk about this some more and introduce more parts of our process and more about Code Review as a feature. Alternate: We’ll be following up with more resources to explain the code review process and how it fits your team. Please tell us what you think. In Beta testing the feedback was overwhelmingly positive, so we’re very excited to have it become a part of your workflow. We’re certain this will enable your team to ship your work on time with less bugs.