Working with Continuous Integration & Delivery (CI/CD) on GitLab

Can working with CI/CD improves your software development workflow?

Working with Continuous Integration & Delivery (CI/CD) on GitLab


As primarily a repository management suite, GitLab also offer Continuous Integration and Delivery tools that allow you to process builds such as checking linting, tests and code quality for deployments.

Nowadays, you have such tools to automate builds and deployments processes compared to previous technologies. For instance, when I previously worked on PHP, after iterating a feature, I just deploy the codes in the server through FTP. Even though the codes were hosted on an locally hosted version of GitLab, there was no such modern tools.

With the advent of Docker, Kubernetes and applications using multiple containers deployed on several servers, automating build and deployment is becoming a standard - as it can itself become a full time job, known as DevOps.

What are the pros of this workflow?

The use of CI/CD workflow forces a standard or structure to be used throughout the project thus making development more determinant. This makes it easier to work as you know what to expect, for instance, similar way to declaring variables or naming files. Even the project newcomers will find it easier to learn the ropes - which is an enormous boon of productivity - both on the short and long term.

Moreover, in regards to JavaScript, by default, unless you are using a framework such as Angular or NestJS, there is not much order or structure. You can follow style guides such as AirBnB. Otherwise, anyone can pretty much code like they want. This sounds easier to begin with, but over the long haul, the project becomes far more complicated. I experienced this situations a few times when junior developers did not or had difficulty following the existing conventions as they were no official restrictions as such. But with CI/CD, you can enforce styles and lints for instance - that forces a specific type of development for the pipelines to succeed, that is, for the codes to be accepted for merge requests.

With such predictable approach, documenting the project becomes easier.

Photo by Christopher Gower / Unsplash

What are the cons?

Configurations for code quality, builds and deployments can take a lot of time. This can be an overkill if you are working on a relatively small code base or team. At the start of a new Minimum Viable Product (MVP) or Proof Of Concept (POF), you want to be able to deliver iterations as quickly as possible; which makes it harder with too many configs.

In my experience, they take a few sprints or iterations to get right and for a small team working on.

Additionally, pipelines and merge requests take plenty of time and resources on the repository server, which can limit productivity.


The CI/CD workflow provides an excellent tool for refactoring and adding new features because you know when something will break. This helps you fully concentrate on your task at hand and be confident of the code base instead of walking on mines.