The GitLab CI Manual: The Textbook You’ve Always Needed — #1 Introduction

Preface

Before diving in to the basics, this post would like to implore the reader to look up definitions of all the technical jargon that will naturally follow in the series. You cannot build a technical understanding of the structures involved unless you’re proficient in the language it speaks.

Note: All technical jargon will be marked with an asterisk (*), making it easier to identify them for lookups.

This is the first in a 5-part series that aims to act as a manual to developers who are either starting out learning GitLab CI/CD or more senior devs looking for a handbook.

First order of business — What are CI/CD pipelines, and why GitLab?

In order to comprehend the concept that is automation and pipelines, we need to trace the history of why these things came into place, the technologies that came after and how refined they became over time.

To give a brief introduction, before pipelines, developers had to manually set up everything — from installing dependencies required by apps to setting up infrastructure for their projects to run.

After the advent of scripting, it became a lot easier to automate manual tasks with the run of a single .sh file. But scripting brought up its own sets of problems, one of them being deployment.

Deployment was still done manually, because scripting produced many errors such as:

• Silent Failures — Scripts return a success exit code (0), but they do not stop executing after a command fails, unless explicitly written otherwise using set -e.
• Unset Variable Issues — Scripts depend on the host environment. If a variable is mis-spelt or missing on the production server, then the entire script breaks.
• Unverified Releases — Running scripts without automated health checks can leave services in a broken state without anyone knowing the root cause. And thus, to fix such problems, pipelines were born.

CI/CD Pipelines — Demystified

CI/CD pipelines are Continuous Integration/Continuous Delivery tools that aid in automating 90% of the work that you would have otherwise done manually, such as deployment, setting up infrastructure on a server, etc.

Any changes you make in your code base or structure immediately get integrated and tested by the pipeline — the Continuous Integration part — and then deployed to a cloud platform of your choice, which falls under the Continuous Delivery section (AWS, Microsoft Azure, Google Cloud, etc.).

There are many CI tools that came about after the advent of pipelining. A few notable ones are:

• GitHub Actions, as provided by GitHub.
• GitLab CI, as provided by GitLab.
• Jenkins, which is an *open-source downloadable automation tool that is hosted on a server locally, such as an EC2 Instance or a Kubernetes cluster.
• CircleCI, which is a *SaaS platform that integrates across all repositories, such as GitHub, GitLab, BitBucket, etc.

There is no “proper” or “best” pipeline, since the primary work that each tool does is automation, while offering different sets of features, such as GitLab CI offering native *Terraform integration, whereas GitHub Actions — being relatively new — does not, requiring third-party support. But that is about the degree to which the distinction between each pipeline goes.

Of course, the choice varies from company-to-company. The employee must, then, learn to be flexible to suit the company’s requirements.

Why GitLab CI? Why not other CI tools?

Herein lies the “paradox of choice”. There are several repo-hosting platforms available that offer CI/CD capabilities, so choosing each depends on the pros and cons of each platform, along with the needs of the individual/team.

A table is then best suited to provide a more direct comparison between each platform, their benefits, and the costs they offer.

A table is then best suited to provide a more direct comparison between each platform, their benefits, and the costs they offer.

Platform / Tool	Primary Focus	Core Advantage	Best Suited For
GitLab	All-in-one DevOps lifecycle	Native *Terraform integration out-of-the-box	Production-standard DevOps engineering teams
GitHub	Source control & collaboration	Massive marketplace ecosystem of Actions	General development & open-source projects
Bitbucket	Atlassian ecosystem synergy	Built-in Jira and Confluence link tracking	Enterprise environments already deep in Jira
JFrog Artifactory	Universal binary repository	Specialized artifact management & storage	High-scale dependency management & security

Conclusion

While GitHub and BitBucket offer more features in general development — with JFrog Artifactory offering solely binary storage — GitLab stands out as the best production-standard for a DevOps team when it comes to offering a pure DevOps-related repository hosting platform.

And thus, we shall begin by navigating through GitLab and its main attraction point for many developers — CI/CD capabilities.

Any corrections in this post will be much appreciated in the comments!