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.

Pipelines 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.


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.