Moving To GitLab

Posted: February 23, 2016

I’ve been using GitHub as my primary source control platform for the past 5 years. As a web developer there came a point where I needed a better way to keep track of development for clients and also a better way to revert things when I inevitably broke them. As a student GitHub offered me 5 free private repositories, plenty to keep private projects in for the first few months.

Problems

I started by putting all of my client projects in a single repository, freeing up my remaining 4 repositories for use in other projects. However, as you’d probably imagine, this became exceptionally convoluted and complex. Cloning the repository to a local machine too considerable time as there were at least 10 projects in there. Even with stripping as much as possible out of repositories, like excluding the “vendor” directory from Laravel installs (let’s be honest – it should never have been there) the repo was unwieldy. I plunged $10 a month into increasing my private repository count, splitting my client projects to individual repositories, but as my client base continued to increase I found myself needing more and more repositories.

Today, I have 22 private repositories. In some ways this is great because I can add clients to repositories so they can see what I’m doing and contribute issues to the tracker. But there is one barrier to me – cost. GitHub has a tiered pricing policy, meaning the latest 2 repositories push me into the $50/month price bracket. That’s up from $22 for having 20 private repositories. As my client base is increasing, I’m gaining more and more repositories, and quite honestly I don’t know what happens when I reach 50…

At this price point I’m paying almost $2.30 per private repository, compared to the $1.10 per repository when I was using only 20. This is my issue with GitHub as a platform, their tiered system forces you to pay for services you’re not currently using, instead of charging you individually for the number of private repositories you actually have in use. So this week I decided it’s time for change. I have recently built a new home server [link], with plenty of overhead to run a self hosted SCM solution. I looked at a number of options and decided on GitLab – and I love it.

Why GitLab?

GitLab Community Edition is free, and comes with its own continuous integration (CI) software, allowing me to run tests and deploy code every time I commit. Previously, I ran Jenkins CI on my ChemCraft server to perform these tests, as well as automate the build of ChemCraft from source, but now I can do this directly on my own server.

The upside of this is that my webserver is now much less taxed. Although I’m not running any high traffic sites from it, and it has a decent amount of CPU power and RAM with 2 vCPUS & 2GB RAM at DigitalOcean (you can read more here), Jenkins CI seemed to eat RAM, even when idle. My new NAS – Zeus – has plenty of RAM, and can easily be upgraded for a one-off cost. This should mean I don’t have to upgrade my DigitalOcean plan any time soon either!

Self Hosted vs. GitHub

GitHub is a tried and tested platform, and I have no reason to believe that GitHub doesn’t have adequate safeguards in place in terms of data redundancy and security. On top of that, I don’t have any code on GitHub that I don’t have a backup of. That withstanding, I’d still rather not keep my client code on a service outside of my control. If GitHub was to disappear overnight, I’d rather not keep all bug tracking and commit history there. GitLab allows me to keep all my code, commit history, issues, and comments on hardware I control. I know that my RAID setup provides adequate redundancy. It feels more safe.

Permissions & Features – The Differences

GitHub has a number of great features, offering permissions and social features. The permissions system allows repository owners to allow access to the certain people, or team members. GitLab expands this functionality, allowing repository owners to allow access to specific parts of a repository – say the issue tracker, or the wiki. On top of this, GitLab offers a number of social features on top of those offered by GitHub. You can share code snippets, without sharing a whole file, and set milestones at a group level instead of a project level.

Overall Impressions

Overall, I really love GitLab. Importing my projects directly from GitHub was simple (once I setup OmniAuth within GitLab), and imported all commit history and issues. It should be noted that all comments and issues were put under my user account, but that was expected – after all, the original commenters don’t have accounts on my GitLab instance. The interface is clean, and setting up repositories and groups (teams) is simple. Most of the settings are simple with most being easy to understand. After initial setup, almost all settings can be modified within interface. Once exception to this (which I guess falls under “initial setup”) is the addition of OmniAuth information for GitHub/BitBucket and the like, which requires you to modify configuration files. But after one time setup you never need to do it again.

So if you’re looking to move away from GitHub, and you have hardware sitting around (or a hosted server) to host GitLab on I would definitely recommend it!

© 2012-2019 Tom Kent. All Rights Reserved