I’ve started moving all my projects away from Github in favor of Gitlab, and I haven’t looked back.
I should say upfront that I’m not affiliated with nor employed by Gitlab. I haven’t been paid, prompted, or asked by Gitlab to write this post. And, as far as I know, Gitlab has no idea I’ve written about them.
My favorite Gitlab Features
- Unlimited free closed projects, like Bitbucket
- Painless Github importer
- Remove source branch after merge to master automatically
- Merge branch when tests pass automatically
- Create a branch from a issue in website; auto-resolve issue when branch is merged
- Integrated approach to software development makes it easier see what’s happening in my project
- Excellent issue tracker / basic project management
- Integrated CI with excellent documentation
- Proper docker support in CI (not a forked build of docker)
- Builtin Docker image registry
- Build environment can be any docker image
- Parallel builds in CI
- API for CI
- CI Deployments track where your code is deployed to (I use this feature to render previews of my blog on S3 on a per branch basis)
Gitlab is more innovative
Gitlab has pioneered a plethora of new features before Github, Bitbucket, Gogs or any of the other competitors in the space. Gitlab’s commitment to open source product direction, incident response, and source code means that I have insight into the product roadmap as well as the ability to contribute my feedback and features.
By comparison, Github has more-or-less copied a few of the best project management features but still lags behind Gitlab in terms of basic features like “Merge on Test Pass” and “Remove Source Branch on Merge” features. Github itself is 100% closed source and notorious for its lack of transparency in terms of product direction. Github eventually added the ability to rebase-merge, and create issue templates months and months after Gitlab. By choosing to use Gitlab, you’re getting the best new features right away.
GitlabCI is competitive
Let’s talk about GitlabCI. Here’s a quick comparison (due to age poorly) between the major continuous integration and continuous deployment options in the space:
|VCS Support||git||git||git||git||git||any via plugin|
|Github Support||no, but..||yes||yes||yes||Yes||plugin|
|Bitbucket Support||no, but..||no||yes||yes||Yes||plugin|
|Founded||2011||2011||2011||2011||???||2004 (as Hudson)|
|On-premise Option||CE & EE||No||EE||No||Yes||Yes|
|Linux Test env||Yes||Yes||Yes||Yes||Yes||Yes|
|OSX Test env||Not Cloud||Yes||Yes||Not Cloud||No||Yes|
|Windows Test env||Not Cloud||No||No||Not Cloud||No||Yes|
|Docker support||BEST EVER||Yes||Awful||Yes||Yes||Yes|
|Free Closed Source Projects||Yes||No||No||1 project||On prem||On prem|
|Source Controlled Config||Yes||Yes||Yes||Yes||No||No|
|Secrets management||Web||YML & Web||Web||Web&docker||Web||Web|
|Parallel Build “Steps”||Yes||Yes||Yes||Yes||No||No|
|Parallel step rerun||No||Yes||No||No||No||No|
|Integrated Docker Registry||Yes||No||No||No||No||No|
|Deployment targets||Yes||3rd party||3rd party||3rd Party||3rd party||plugins|
One of the key differentiators above is the ability to run the CI locally. This is really really handy for two reasons:
- Increased fault tolerance: even if your remote CI infrastructure is down, you can still run builds and deployments.
- Debugging: its potentially much faster to iterate on a broken test locally
Both GitlabCI and Codeship are designed to help with the second bullet point. GitlabCI also provides the increased fault tolerance that I often wanted when I relied on CircleCI.
For me, GitlabCI is the most exciting CI option available, especially in the build-on-mac-and-deploy-to-linux scenario.
Gitlab unifies all (or most) of the different services you previously relied on when using Github, but is flexible enough to work with other systems (via triggers, API, and webhooks) or simply does a better job than Github + other services. If you’re thinking about making the switch, I’d encourage you to try out the gitlab.com for your next side project or open source project.