Why we switched to GitLab
One of the first services you sign up to when creating software is an online Source Control Management (SCM) service. GitHub is the largest and the most well-known, and was the first service we signed up to.
One of my colleagues suggested we try GitLab. I was initially apprehensive - I like to use standards and whatever the masses are using. I use BitBucket for personal projects (and liked their free unlimited private repositories - up to 5 users), but hadn’t ever used GitLab.
What made the decision easier was …pricing! GitLab has an awesome free plan: Unlimited private projects and collaborators for free. We initially would have at least a dozen contributors on our project, so this sealed the deal!
Initial Impressions
Git is Git. At least from the command line, or through a GUI (I tend to use SourceTree for visualizing changes). So initially it makes no difference what service you use. It’s the add-ons and the extra functionality that really differentiate the choices.
Photo by Quinten de Graaf on Unsplash
GitLab, BitBucket & GitHub offer Issue tracking & documentation (via wiki), but GitLab has taken a different approach by including CI/CD pipelines.
Continuous Integration & Delivery Pipelines
GitLab CI/CD Pipelines enable building, testing, deploying & monitoring code. There’s a lot going here. Back in my previous post File > New Project I said:
“It’s amazing how much CI/CD improves outcomes by encouraging regular delivery of small pieces of functionality. The DevOps mindset.” - Tim Bray, 2018
It’s essential for successful projects. Using this DevOps mindset from the start of a project is super helpful. Having this built into the platform makes a lot of sense. As long as it works…
It’s super easy to get started just put a .gitlab-ci.yml
file into the root of your project and configure a Runner to execute the commands. The yml file will contain options (eg. branches to monitor) and build, test or deployment commands. Whenever GitLab sees a new commit or push in a monitored branch, it will start a new Runner and execute the appropriate commands from the .gitlab-ci.yml
file.
I’m not a fan of yml
, but it is pretty easy to understand. What is a painful, is testing your configuration. This is usually some trial and error, make a change, commit/push, watch how it worked & repeat. Although, GitLab does have a CI Lint tool that checks if your yml is valid.
Summary
I expected to use another tool for our CI/CD piplines. Having this inbuilt into GitLab enabled us to get our pipelines up and running quickly. Can’t argue with the price either.
I expect in future we’ll outgrow GitLab’s CI/CD and want to use something more sophisticated, but until then we’ll concentrate on coding and building our software.