Moving And Consolidating: Code Hosting

We started an initiative at Infinity Interactive a few months ago to consolidate and simplify the various support systems we use in our work.

Criteria

The first step in our journey was to make a list of the features we needed so we could measure how well each possible provider fit the bill.  Our requirements were:

• Git support
• Subversion support
• Simple administration
• Support for at least a hundred repositories

The combination of Git and Subversion was the most restrictive.  Many of our clients still prefer Subversion so it was important that we be able to work with either system.

The simple administration was important to decrease the internal bottleneck of system administration.  We were specifically looking to decrease the number of machines and services we were managing internally.

While we were happy to decrease our administrative overhead, we also realized that hosting code externally could be problematic for a few of our projects.  We sometimes manage large files in the repositories and hosting our code externally would create slowness in checkouts of these large files.  We decided this was a limitation we could factor into our plans or mitigate with separate tools later.

The Players

After evaluating various providers we first settled on Beanstalk.

The Good

The honeymoon with Beanstalk was pleasurable. We began to spin up lots of repositories and use them in day-to-day projects. The interface was simple and effective.  We made use of the deployments feature to push code out to our QA instances. The color-coding of repos was somewhat useful and the availability of an API was handy.

The Bad

The downtime.  It wasn't frequent that Beanstalk would have trouble, but it was often enough that it became frustrating.  We were using it with Lighthouse – which is a whole different post – and each of these products had occasional, middle-of-the day outages.

And it wasn't as nice as GitHub.

GitHub's Subversion support was announced on April Fool's Day, but it wasn't a joke.  A month later they announced write support. This feature isn't advertised much on their website, so it is understandable that we missed it initially and why we were hesitant to depend on it.  Eventually we tested it more extensively and found that it worked well.  Recently they announced even more features.

When comparing Beanstalk to Github we constantly found Beanstalk coming up short.  First, we all have GitHub accounts for our personal code. Second, we missed some of the features that had become so helpful for our personal use: Markdown rendering, super easy forking and pull requests and wide integration with other products.

Home Sweet GitHub

After suffering another outage or two with Beanstalk and realizing that Subversion worked well with GitHub, it became obvious that switching to a GitHub Business Plan was the right thing to do.  We opened an account and added everyone's personal accounts to our Organization.

Many of our repositories were moved very quickly after opening our account.  The Subversion-based repos were a bit slower to migrate, the last one being moved just today.

We've been very happy with this change.  Everyone loves having their work and personal repositories separated, but in the same general place. Much of our work involves other open-source repositories and the convenience of GitHub has been a huge boon.

Not All Roses

That being said, GitHub isn't perfect. We often hear complaints about the "context" switching as users switch between their personal account and the organizations they are in.  We quickly blew past the smaller accounts and had to upgrade to their biggest one.  We have a small number of employees compared to the number of repositories we have.  The price, however, is reasonable for the features they provide and the steady march of new ones they debut.

One little complaint: We miss pre-commit hooks.  We'd love to be able to reject commits that don't reference a ticket.

Success All Around

While we ultimately ended up choosing GitHub, we likely appreciated it more because of our experience with Beanstalk.  All of our developers are more efficient and our interactions with external projects and developers work better.  Thanks, GitHub!