A lot of people lately have been looking into moving from Github to Gitlab. Mostly because of Microsoft’s acquisition of Github (set to finish late 2018). I do have my own views on this acquisition, but that’s not the point of this blog. My reasons are to really get into why we (at Tevreden.nl) chose to move from Github to Gitlab, and -spoiler- it’s not Microsoft. I will be going through are reasoning behind this move in a short point-by-point basis. Just a small disclaimer: I’m in no way, shape or form affiliated or payed by Gitlab.
Gitlab has a rapid development cycle
We just weren’t feeling the rate of new features being added to Github. There was a lot to do about this in the past, with a lot of open source projects complaining. It went as far as some open source contributors writing a letter (https://github.com/dear-github/dear-github). The rate of development at Gitlab is staggering, releasing at least once a month. These releases add a lot of value and features that users wouldn’t even think about.
Integrated CI
One of the biggest things for us to move is that we had a setup previously with multiple components (Github, Jenkins & JIRA). We were looking for a good alternative to combine these three separate components into one solution. One of the most important things was a CI solution, which Gitlab has already built-in.
Gitlab CI can be used with multiple executors for the build environment (SSH, shell, VirtualBox/Parallels, Docker, Docker Machine & Kubernetes). In our case we’ve decided to use Docker, mostly because of the build environment being cleaner, and also we output to a Docker image anyway, so Docker was the way to go for us.
The CI is easily setup using a .gitlab-ci.yml file, one of the big reasons we moved away from Jenkins (yes, I know Jenkins supports this as well). This gitlab-ci.yml file is good because it’s version-controlled and any changes will be stored. We’ve just recently moved away from Jenkins completely. To see more about Gitlab CI, check out this link.
Issue Boards
Looking at the requirement we had of also replacing JIRA, we were also looking at Issue Boards. Although Github did implement this feature not too long ago, it’s still really basic and just not suitable for a more complex workflow. Gitlab supports multiple Issue Boards (available from Starter packages), not something we use right away, but good to have. The Issue Boards are easily setup with multiple swimming lanes, and also swimming lanes based on labels within issues. We’ve moved away from JIRA to use Issue Boards completely. For more about issue boards, check out this link.
Community Edition
Having a Community Edition and package that everybody can use for free (self-hosted) is a big plus. It means that we are free in creating as much private repositories as we want, of course within the realms of what your server(s) can handle. The community edition does not skimp on features either, altough it’s preferable to go to the Starter Edition. One of the reasons you would like to do that is the ability of just being able to assign 1 person to a merge request. Other than that, we haven’t found any real reasons to go away from the Free Community Edition.
Kubernetes Support Built-In
Maybe a smaller and future thing for us. We’re using Docker Swarm at the time of writing and are really looking into Kubernetes. Having Kubernetes support built-in would improve our CI process even more, so it’s nice to know we’re future-proof.
Conclusion
Although I’m aware not everyone would like to go trough the hassle to self-host and move away from Github, for us it payed off. I wrote this article to explain our reasons, and I hope this helps other people facing the same question out. Are you also thinking about moving or want to reply on this article, go ahead and leave a comment below.
Have you checked out the Bits vs Bytes podcast? You can find it here.