Updated commentary on Github’s installation process in response to comments made by Christian Johansen.
Since decentralised version control became all the rage, at Box UK we’ve been making a steady transition from Subversion towards Git. Prior to beginning the move there was understandable concern that a new system for developers to learn, and changes to our deployment process, could harm productivity. In reality, however, the switch was smooth. We invested in training materials (including a few different books for our library, and the O’Reilly ‘Mastering Git‘ video tutorials which I’d particularly recommend) and employed a bunch of fresh-faced younglings who’d probably never even heard of Subversion (or, shudder, Accurev) and everyone got on quite well with things.
We use Redmine to provide collaborative features for our Subversion repositories – source browsing, issue tracking, code reviews etc. We were already familiar with GitHub, a similar solution for Git with added social networking features, and resolved to use it with our new VCS. At first we were only using GitHub for our open source offerings which meant that we didn’t have to worry about any financing (GitHub is free for open source projects), so we were up and running without having to bother anyone for a credit card, which is always welcome. Soon we decided to kickstart development of our OS libraries in private until they were ready for public consumption, so we upgraded to a private (paid) account. At this point we were using GitHub exclusively for developing and hosting our OSS projects, with repositories for our proprietary code remaining in Subversion.
Box UK’s GitHub page
After getting some Git experience under our belts we decided to use it for new proprietary projects too, but the repository cap on our GitHub plan initiated a search for an open-source solution that would allow us to scale without worrying about cost. That led us to…
At first glance a promising facsimile of GitHub, Gitorious was a leading candidate. Most of the features we appreciated in GitHub were present, including merge requests (or pull requests), team management and activity monitoring. The UI wasn’t as presentable, but it was functional. And crucially, we could install a local version within our network, which meant our repositories could be included in our existing backup solutions and wouldn’t be dependent on a third party.
Unfortunately the biggest problem we found was the installation process, which turned out to be tricky, mostly due to a lack of documentation and some difficult to resolve RubyGems dependencies. Once we had it set up, though, it served us well for around nine months, until we came across…
We didn’t have the option of Gitlab when we decided to go with Gitorious, but in the time that we were using the latter Gitlab went from strength to strength, adding features at a rate that outpaced its rival. Gitlab has a number of advantages over Gitorious. It runs on top of Gitolite, which furnishes the standard Git toolset with some powerful features like access control. This in turn allows Gitlab to offer features like protected branches, which fitted nicely with our ‘stable master’ approach to release management (where the master branch is fit to be deployed at any time) – protecting the master branch means no code can be merged to master without passing a code review by an authorised developer.
Gitlab in general was much closer to the GitHub-like solution we craved – open source, written in Ruby on Rails and hosted on GitHub itself (which opened the door for us to contribute back any features we added), and aside from a few niggles (a lack of fine-grained team management, and some annoying bugs around diffing code merges) it was much better received by the team than Gitorious had been. A timely release schedule (a release each month, at the time of writing) gave us heart that any issues we did encounter were not going to inconvenience us for long.
The Gitlab page for a Box UK app
Ultimately though, even though it worked well we decided that Gitlab wasn’t going to be suitable – as we had found with Gitorious, maintaining it proved to be a problem. Despite the superior installation process, this time saving was soon absorbed in having to upgrade Gitlab every month. Regular new features also mean regular regressions and bugs, which was something we couldn’t swallow given how important the component is to our development workflow. Ideally we wouldn’t have upgraded as regularly as each release, but as the product is relatively immature releases tend to contain must-have features.
We analysed the effort we were putting in to host our own solution and determined that it worked out cheaper for us to just upgrade our GitHub plan and move wholesale to that platform, especially when factoring in the excellence of critical features like code reviews and pull requests. It also meant we had a unified solution for all our Git projects, both open source and proprietary, which removed the potential for confusion. I miss the protected branch feature from Gitlab, but overall it’s a worthwhile trade off. Making a third party responsible for hosting the masters of one’s mission-critical code is a significant risk, but it is a risk we mitigate by scheduling regular “off-site” backups of the repositories.
Upgrading to GitHub was totally painless. We simply created repos on GitHub for everything we had on Gitlab, and mirrored them using a helper script:
git clone –mirror email@example.com:$1
git push –mirror firstname.lastname@example.org:boxuk/$1.git
This is the beauty of a distributed VCS: its very design makes changing a hosting solution incredibly easy. Within a day, all our projects were migrated, our Jenkins builds updated, and our developers were happily working with GitHub.
I wouldn’t recommend Gitorious at the moment; it has some catching up to do if it is to rival Gitlab as a local solution, though it does offer a hosted option too – but in that case I’d just go with GitHub from the off as it’s well worth the additional cost. Our feeling was that perhaps the Gitorious team haven’t made it as easy as they might for people to locally install the product in order to encourage paid hosted users – understandable perhaps, though it doesn’t help us in any fashion., but according to Christian Johansen, a Gitorious team member, Gitorious’ installation features were not deliberately deprioritised – please see his comment on the 22 Oct 2012 for more details.
I’d recommend Gitlab to anyone looking to self-host their Git management platform while requiring many of GitHub’s features, as long as the resource is available to support and manage it. It’s really suited for a group of 2-10 developers. It doesn’t support ‘public’ repositories so it’s also aimed at companies wanting to manage their proprietary code.
So, finally, with GitHub we appear to have settled on the best Git hosting solution for us. It seems you really do get what you pay for.
Any questions about any of these products? Leave a comment and I’ll do my best to answer them.