CI/CD tools landscape

GitLab CI, GitHub Actions, Jenkins, CircleCI, Argo CD: who's who and how they differ. Lesson goal: open someone else's repository and tell, from a single file, what the team's CI/CD runs on.

Why this matters

At a new job, nobody's going to ask which engine you like. You'll get a repository with a pipeline already in place, and the first thing you need to figure out is where its config lives and who runs it. There are many tools, but only two groups, and the concepts are shared across all of them.

Two big groups

CI/CD tools split into two categories.

1. Pipeline engines run builds, tests and deploys on an event from git: a push, a merge request, a tag. This group includes GitLab CI, GitHub Actions, Jenkins, CircleCI.
2. GitOps tools for Kubernetes make sure the cluster's state matches what's recorded in git. These are Argo CD and Flux.

Most beginners start with the first group. GitOps comes along with Kubernetes.

Built into the git host

GitLab CI/CD. The config lives in a .gitlab-ci.yml file at the repository root. CI is built right into GitLab, there's nothing separate to install. The registry, environments and branch protection all live in the same interface. This site is itself built on GitLab CI, and we'll go through its actual config in the next lesson.

GitHub Actions. The config is a set of YAML files in the .github/workflows/ folder, each file describing a separate workflow. Actions has a huge marketplace of ready-made actions, that is, reusable steps (uses: actions/checkout@v4). For projects on GitHub it's the de facto standard.

They share one trait: CI lives next to the code, the config is a YAML file in the repository, and it runs on a push or an MR. Learn one, and you can read the other with almost no extra training.

Standalone servers and cloud engines

Jenkins. The old-timer, runs as its own server. Very flexible, with thousands of plugins. The pipeline is described in a Jenkinsfile, a DSL on top of Groovy: blocks like pipeline { agent ... stages { stage('build') { ... } } }. The downside is maintenance: the server itself, the plugins and their updates stay on your team. Jenkins lives on in a lot of legacy code, and gets picked less often on new projects.

CircleCI runs in the cloud, the config is also YAML, living in .circleci/config.yml. It's now being squeezed out by the built-in GitLab CI and GitHub Actions.

Travis CI was popular in the open-source-on-GitHub era. In 2021 the free travis-ci.org shut down, and open-source projects moved to GitHub Actions en masse. You'll still run into a .travis.yml file in older repositories.

Drone still gets presented in articles as a living open-source engine, though that's no longer true. In 2020 the project was bought by Harness. Now the harness/drone repository holds Harness Open Source, and Drone's code sits on a separate, shelved branch. Back in 2019, when Drone changed its license, Woodpecker CI forked off from version 0.8. It's the one people pick when they need a lightweight, Drone-style self-hosted engine. Woodpecker's config lives in .woodpecker.yaml or in a .woodpecker/ folder.

GitOps: Argo CD and Flux

A separate approach for Kubernetes. The idea: git serves as the single source of truth for what should be running in the cluster. The repository holds manifests, that is, a description of the desired state. An agent in the cluster constantly checks reality against git and pulls in changes on its own.

• push model (regular CI): the pipeline itself goes into the cluster and deploys. It needs access and keys to the cluster.
• pull model (GitOps): an agent inside the cluster pulls what should be running from git on its own.

The pull model has two advantages. The cluster doesn't need to open access from outside. And if someone changes something by hand (drift), the agent rolls it back to the state from git. Hence the rule: in a GitOps environment, changes are made as a commit, not a command against the cluster.

Argo CD and Flux are the main tools here, both CNCF graduated projects. You can recognize them by their manifests: Argo CD has an Application object with apiVersion: argoproj.io/v1alpha1, Flux has GitRepository and Kustomization objects from the *.toolkit.fluxcd.io groups. GitOps gets covered in depth after Docker and Kubernetes, here it's just for the overall picture.

What they all have in common

Don't fixate on a specific tool. The concepts are the same everywhere:

• config as code in the repository (usually YAML, Groovy for Jenkins);
• stages and jobs, runners or agents that execute them;
• secrets in storage, artifacts, environments;
• triggering on a git event.

Once you've learned CI/CD on one engine, moving to another takes a day: the syntax changes, the ideas stay.

What a beginner should pick

Take whatever engine is built into your git host: GitHub → Actions, GitLab → GitLab CI. No server to stand up, everything lives next to the code, and the skill transfers straight to a job. Learn Jenkins when you run into it in legacy code. Argo CD or Flux once you get to Kubernetes.

Common mistakes

• Only looking for the CI config at the root. GitHub Actions keeps it in .github/workflows/, CircleCI in .circleci/, Woodpecker can have a whole .woodpecker/ folder. Hidden folders show up with ls -a.
• Confusing Argo CD with a pipeline engine. Argo CD doesn't build images or run tests. It only brings the cluster to the state recorded in git. The build is still CI's job.
• Fixing a GitOps environment by hand. A command against the cluster helps for a minute, then the agent puts everything back the way git says. An edit that should stick goes in as a commit.
• Picking a tool based on a five-year-old article. Drone and Travis CI look alive in old overviews. Check the repository and the release dates.

What to remember

Two groups: pipeline engines (GitLab CI, GitHub Actions, Jenkins, CircleCI) and GitOps for Kubernetes (Argo CD, Flux).

The ones built into the host, GitLab CI and GitHub Actions, give you the best start: YAML next to the code, nothing to install.

Jenkins is powerful but needs its own server and shows up more often in legacy code.

GitOps means git as the source of truth and a pull model: an agent in the cluster pulls in changes on its own and rolls back manual edits.

The tools differ, the concepts don't. Learn one, and it carries over to all of them.

What you'll need for the tasks

• Lab 1: just a terminal. The ls -a, find, cat commands, and the ability to recognize an engine by file name and by the first lines of its config.
• Lab 2: Docker, git and bash. The lab environment plays a GitOps agent: every few seconds it checks the containers against a file in a git repository. You'll need to remember how to make a commit (git add, git commit).

In the next lesson we'll go through the real .gitlab-ci.yml that deploys this site.