GitLab First Impressions
I’ve been tasked with researching GitLab and setting up a demo for it at my work. We’re considered moving some internal build and deploy pipelines over to it. My intentions with this type of post is simply to keep some notes on the technology as I learn it. Hopefully my notes will be of some use to you.
Features Overview
It seems like GitLab and Bitbucket share a lot in common, but that GitLab has a larger set of features with more integrations for other technologies. They both have highly customizable pipeline definitions in the form of YAML files stored at the root level of the repository. They both can track new branches, pull requests, and merges, using different build and deploy logic for each type. From my research, however, it seems GitLab is just a bit more flexible than Bitbucket. For example, their YAML files are largely the same, but GitLab supports additional features like monitoring changes in specific files and ignoring builds if those files haven’t been modified. This allows for building only changed components. Bitbucket only works with Bitbucket repos, but GitLab can integrate with GitHub and Bitbucket, or host your own git instance for you. So far, it seems GitLab has a little more polish and be stretched a little further than Bitbucket.
Pricing
The pricing model seems a little convoluted at first. Reading up on it, you see GitLab is based on an open source software. So you can host it yourself if you wanted. However, there’s a SaaS based Enterprise version of it you can pay for, which seems to come with a lot of features. But then there’s also the self-hosted Enterprise pay-as-you-go plans too. There’s build minute caps, but these are termed as runner minutes. After some research, you find out runners are just build agents or slaves. And, of course, you can host your own runners with any of the above hosting options, taking another limit off of this complicated pay model. These have been pretty confusing to navigate and figure out. Here’s what I understand so far:
SaaS Enterprise plans
- Most features
- Most expensive
- Least setup work
- Support
- Runner minute caps
Self-hosted Enterprise plans
- Same features as SaaS
- Same price as SaaS
- More setup work
- Support
- No runner minute caps (you’re hosting the runners)
Open-source self-hosted
- Least features (core app only)
- No cost
- Lots of setup work
- No support
This is a pretty basic outline of their pricing model, but it’s the most important part of it from what I can tell. Based on this I’m actually not sure if it’s worth it to use the SaaS plan and host your own runners or to just self host entirely. If you’re going to need to get around runner limits and host your own agents, then I’m not sure it’s worth it to pay just the SaaS plan. On the other hand, you eliminate a bunch of setup work on your end, and it takes less resources off you for them to handle hosting the UI and dashboards. For now I’m opting to use the SaaS solution with GCP runners, but I’m not committed hard to anything right now.
General Use So Far
In playing around with GitLab so far, it’s been pretty intuitive and quick to get stuff done. I set up a mirroring rule, so that I could play with our repo on Bitbucket without transplanting the whole codebase to GitLab. Then I went about looking at runners. I quickly had an SSH runner setup, and then even quicker a Kubernetes runner on GCP. In writing pipeline files and modifying Kubernetes runner configs, everything has been smooth and steady. I run into errors, of course, but they’re easy to diagnose and are resolved fast, so far. First impressions have been great with it.
I’ll have more posts coming on GitLab regarding: their pipeline files, Docker in Docker issues, and a final overview of what direction my company ending up going in.