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.
With such predictable approach, documenting the project becomes easier.
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.
Originally published at http://126.96.36.199 on August 8, 2019.