We have been looking for ways to solve the most expensive problem in software - managing big projects. I suspect that new solutions to this old problem will come from big open source projects.
Gerrit was built by Google to handle code contributions for one of the biggest, hottest open source and "ecosystem" projects ever attempted - Android. See it in action here. From there, it has spread to major Android contributors like Ericsson and Qualcomm, where it serves thousands of engineers, and to related projects like JGit and EGit at the Eclipse Foundation.
Many open source projects feed changesets to a "maintainer". The maintainer "pulls" the changesets, tests them, and then merges them into a master branch. This is the workflow supported on sites like Github, Gitorious, Bitbucket, and Launchpad. We implemented a similar workflow with fork and merge requests. This workflow has some problems with scalability. The maintainer works alone, or as part of a small group. That creates a bottleneck. And there is a lot of merging, as each participant in this distributed process maintains his own version, rather than just working off a shared branch.
So, my ears pricked up when I was at SAP last summer, and we showed our fork-and-merge workflow to an engineer named Matthias Sohn, and he scoffed. He said it was baby stuff. He told us about Gerrit, which he was using in his work with the Eclipse Foundation and EGit. In his mind, Gerrit could deliver the quality and scalability that SAP needed, it was simple and effective, and nothing else was worth bothering with.
A code review system based on voting has big advantages for projects that need to scale. You can have any number of voters and approvers. So, you can handle a high volume of contributions.
Instead of obsessing about top-down project management, you can just let the developers work, and use a system like Gerrit to filter the incoming code so you get the output you want. Tough jobs like enforcing a policy of coding standards and automated tests become as simple as a "no" vote. It cuts through management issues like Hercules cutting the Gordian knot.
We decided to try it as an experiment. Over the past few months, we moved Assembla product development to Gerrit, and then worked on ways to integrate it with our own on-demand tools.
Announcing Gerrit on-demand
Today we announce the beta release of Gerrit on-demand. Now, you can get it on-demand here in a full-featured workspace.
What does it do?
The Gerrit project describes itself as "a web based code review system, facilitating online code reviews for projects using the Git version control system."
Use Gerrit to:
* Push changesets or "patches" to a Gerrit server. The changeset does not go directly into the target branch. Gerrit adds a "change-ID" and creates a review page for the change.
* Invite other team members to review the change, and to vote on it. As this discussion goes on, people can commit amended versions of the change.
* Reset or rebase to a shared branch, and then fetch a single change, and test it. Gerrit gives you a team-oriented work environment where you are testing changes to a shared version of the code.
* You can also set up Hudson (now Jenkins) to fetch each change, run automated tests, and vote "No" if it finds a problem.
* When you have enough votes (usually, plus 2), an approver can hit a button to merge the change into the target branch.
Assembla's version of Gerrit on-demand
Assembla's Gerrit-on-demand contains packaging that makes it easy to get started.
We added our full-featured git tool on top of the Gerrit repository. So, can browse files and branches and changesets. You can trigger builds with the Build tool. You can link commits to tickets by including "re #<ticket>" in the commit message.
The fun starts when you click on the "Patch requests" subtab. That takes you to the Gerrit app.
We replaced the Gerrit authentication with Assembla single sign-on, so you can click directly from your Assembla spaceinto the Gerrit app.
We pulled Gerrit notifications into our activity stream. So, you can see the action and get emailed activity summaries. And, when a changeset gets successfully submitted, it shows up as a git commit event.
We used this documentation to instruct our team. Get an overview from the Gerrit project on Google Code. You can learn more from the Android git workflow, including the workflow map "Life of a patch". Or, get a pitch from EGit contributor AlBlue.
Limitations in the first release of Assembla Gerrit
We made some assumptions about who can vote (Teammates - edit permission) and who can "submit" - accept the changeset and merge it with the target branch (Owners - all permission). The next release will allow you to edit user permissions.
A normal Gerrit server is not multi-tenant. It assumes that all users are part of one big happy family, and it will do things like allow you to search the names and emails of all users when you go to add a reviewer. Our server contains many projects, and we have an obligation not to share email addresses between them, so we show only the login name. There are other places where views are truncated.
In the near future we will link from commit messages to tickets. In the current version, links go only from tickets, so if you comment with "re #99", you will see a link from ticket 99 that says "review".
We normally provide a high level of scalability in our repository clusters. We only have one Gerrit server for this beta release.
We might eventually build our own version of the Gerrit workflow in order to get around some mismatches between the stand-alone application and a multi-tenant application. For now, we are contributing to Gerrit. We are grateful to the Gerrit team for refining this tool over the last two years, and we hope to get some advice from experienced Gerrit users. Tomorrow we will post an interview with Gerrit project leader Shawn Pearce.