Warp Speed with GitHub Enterprise

We've recently switched to using GitHub Enterprise for our product development here at HubSpot, and I wanted to share some lessons learned from how we've made the transition.

So why the move? Previously we'd been using a mix of tools: svn & git for source control, ViewVC for repo browsing, Confluence for shared documentation and Review Board for code reviews, JIRA for bugs. We have a lot of GitHub fans at HubSpot and frankly it is a better and more enjoyable tool set in one place. (And we here at HubSpot certainly appreciate an all-in-one solution since that is what we build for our customers.) It has let us simplify our development process and better collaborate among our developers, designers and product managers. Since the switch there has been a lot of appreciation for the speed of git, pull requests & commit comments for code reviews, the wiki for easy documentation, great code/changeset browsing. There are definitely less expensive options but none stacked up to what GitHub offers. We care deeply about developer happiness and productivity, and this is great advance for both.

The Migration - Make It So

GitHub Enterprise (GH:E) is nearly identical to the public GitHub, but self-hosted as a virtual appliance and with support for LDAP. GitHub has pushed out new versions of GH:E reguarly so it doesn't usually lag by much. The releases are distributed as an OVA format image which we've installed in VMWare. Ours is running on a Dual-Quad Core AMD Opteron box with 16GB of RAM and 5 HDDs in a RAID5 configuration. We had this server handy so YMMV when sizing a machine. The virtual appliance has been stable and has not required much day-to-day administering after initial configuration.

View of a product family & who has contributed

In preparing for our migration the Etsy dev blog post, Moving from SVN to Git in 1,000 easy steps, was very useful. We took a different tack in that we didn't have a single flag day for the move, but instead phased it in over time. The HubSpot architecture is such that there are many independent apps, so it was possible to do in batches. Each team owned moving their apps and ensuring developers were comfortable using git. The biggest decision for us was around what git workflow to use since there are many different ways to use git. We use something similar to what Zach Holman describes in his talk on How GitHub uses GitHub.

Our Voyage So Far

In the few months we've been using GH:E it has been a great experience. A few highlights from our time using it:

• The biggest surprise benefit is that it has made it much easier for the non-developer members of the product team to contribute. Our UX team is using it to share and collaborate on mocks, our product people can change copy through the web UI, and it is easier for everyone to see what changes are happening across the group. The GitHub tagline of "social coding" is very apt.
• GitHub allows pull requests work from branch to branch and doesn't require forking. I think a lot of people have missed this capability. Despite the most recent debate we use both feature gates and feature branches as needed. Both can be used to help keep the number of unmerged commits small, and managing how new features are introduced. 
• Following a suggestion by Etsy's John Goulah (who was generous enough to chat with us before we made the switch), we have put all our team members in one "organization." Managing groups on a smaller scale can be a pain as teams change over time.
• hub is a handy wrapper for git and works with GH:E. Simplifies some common git flows, and hides some of the git command line noise.

Of course there are always improvements we'd love to see in GH:E. Here are a few:

• The code search is okay, but could be improved to allow search over the history of source control and more deeply understand languages. It would be especially handy when trying to track down code in earlier revisions.
• The "news feed" is great when you want to see what is happening across the team. Having even more controls about what projects I see updates for, inclusion of wiki updates, etc. would make it an even better heads-up display of what's going on.
• The Issues functionality is a fine light-weight tracking tool but hasn't won large adoption among our teams. We primarily use JIRA for bugs, particuarly because of integrations with customer support process, and Trello for product backlog feature development.