A CI/CD pipeline automates the path from a commit to production: compilation, tests, publication and deployment, on every change and the same way. This course teaches the model before the tool: reading any pipeline, writing its stages in the repository, building an artifact once and promoting it from staging to production, and spotting the risks of the chain. It is aimed at admins, ops and developers who have never designed a chain, or who copy one without understanding it. Practice happens on a local forge, with no GitHub or GitLab account, before choosing GitHub Actions, GitLab CI or Argo CD.
What you will learn
- Read a pipeline and tell what it runs for a given event
- Write lint, tests and build as repository targets, orchestrated by the pipeline
- Publish an artifact identified by its version and its digest
- Promote the same artifact across environments, then roll back
- Spot the risks of a chain: secrets, triggers, dependencies, runners
Who is this course for?
It targets a beginner in CI/CD, not a beginner in computing. Three prerequisites are enough: making a commit, a branch and a merge with Git (in French); running commands and reading an exit code in a terminal, which the Linux course teaches; reading a simple YAML file (in French), since every pipeline is one. No account on an online service is required.
What the course does not teach is referred to the course that covers it:
the syntax of an engine (GitHub Actions, GitLab CI), writing a
Dockerfile, deploying on Kubernetes and tool-based GitOps (Argo CD, Flux
CD), detailed hardening of a pipeline and the supply chain in depth,
covered by the DevSecOps course.
Why automate delivery?
Take a team of five developers. Every week, the same scenario: a change breaks production, nobody knows exactly what changed, releases happen on Friday night and rolling back turns into panic. This chaos has a name: the lack of reliable automation of the path between code and production.
A CI/CD pipeline solves this problem: it builds, tests, validates and deploys each change the same way, every time. No more "it worked on my machine": feedback arrives within minutes, and what goes to production is what was tested.
CI/CD: what does the acronym mean?
CI/CD stands for continuous integration and continuous delivery or
deployment. Continuous integration tests every change on every git push;
continuous delivery keeps the code always ready to deploy, the release to
production remaining a human decision; continuous deployment sends every
validated change to production with no intervention.
These three levels build on each other: each one includes the previous one, and most teams are better off starting with solid CI. The lesson CI, Continuous Delivery, Continuous Deployment helps you choose the right level, and explains why a human approval is often the right answer.
What is a pipeline made of?
A pipeline is not a script: it is a governed execution system. It splits the work into isolated jobs, grouped into stages that run in order; runners execute those jobs, and artifacts pass results from one job to the next. It keeps the history of every run, is triggered by Git events, and exposes the status of every step.
The table sums up what separates a script from a pipeline. The lesson What is a CI/CD pipeline?, which opens the course, details each of these components, the difference between cache and artifact, and the three invariants a real pipeline must hold.
| What a script does | What a pipeline does |
|---|---|
| Runs on your machine | Runs in a controlled environment |
| Success or failure, no detail | Feedback per step: lint passed, tests failed, build not started |
| No history | Full history: who, when, what, result |
| Started by hand | Triggered by a push, a pull request or a tag |
How is the course organised?
The course follows the path of a change, in four core modules, then two optional modules. A learner in a hurry stops at the end of the core with the course's four skills; the course outline, in the left column, gives each lesson and its duration. The three practical lessons, the progress page and the labs are in French for now.
Understanding a delivery chain sets the vocabulary of a pipeline and the
choice of the level of automation. Integrating continuously has you
write the stages in the repository, as make targets, then the pipeline that
only orchestrates them; it places the tests at the right moment and teaches
failing fast. Delivering to environments has you build an artifact
once, publish it, promote it from staging to production and roll back, then
presents progressive deployment strategies and GitOps. Securing and
running the chain covers secrets, the four attack surfaces of a pipeline
and the anti-patterns that degrade it.
The two optional modules go further without anything in the core depending on them. Organising delivery covers pipeline architecture, trunk-based development, feature flags, the organisational causes of failure and the DORA metrics. Going deeper into chain security covers the ten OWASP CI/CD risks, implicit trust, gates that do not protect, and SLSA provenance.
How do you practise without a GitHub or GitLab account?
The three practical lessons run on a local forge: a Forgejo 16 instance
and its runner, installed in a virtual machine that DSOXLab starts on
your workstation. The forge holds the common-thread repository, inventaire, a
small Python service with no dependency. Nothing leaves for the Internet apart
from downloading the tools, and the machine is destroyed at the end.
The pipeline file there follows a syntax close to GitHub Actions, but
the course does not teach it for its own sake: the pipeline only calls
make lint, make test and make build, which you run identically on your
workstation. That is what makes the model transferable: the same repository
then plugs into GitHub Actions or GitLab CI by changing a few lines. Installing
DSOXLab is described in the DSOXLab documentation.
How is the course validated?
Each lesson, apart from this introduction and the final exam, ends with a quiz that checks what it teaches. The three practical lessons each carry a DSOXLab lab, graded on the state left in the forge and on the machine (green pipeline, published artifact, same digest in staging and production), never on the commands typed.
The core forms a single level, "Understanding and building a delivery chain", which carries the course's own four skills: reading a pipeline and telling what it does on each event, writing the integration stages in the repository, building an artifact once and promoting it, spotting the risks of a chain. The lessons shared with the DevSecOps course add the choice of a delivery strategy and a first approach to pipeline security, which DevSecOps goes deeper into.
Quizzes and labs train you; they are not enough to prove the level. That proof belongs to an end-of-level exam, a broken chain to repair in a lab: a green pipeline that lies, to make honest, then a corrected version to publish and promote all the way to production. It is played without hints, graded on the state reached, and has its own page, in French: Épreuve CI/CD : réparer une chaîne de livraison cassée. It also requires being able to read and fix a Python function of a few lines.
Why is the pipeline a target?
A pipeline has access to secrets, source code and production environments:
compromising it means compromising everything it delivers. In March 2025, the
GitHub action tj-actions/changed-files, used by more than 23,000
repositories, had its tags moved to code that wrote the runners' secrets into
the logs of the pipelines running it. These attacks exploit the implicit
trust given to third-party dependencies and actions.
The "Securing and running the chain" module covers this subject, starting with the four control surfaces: identities, dependencies, runners and artifacts. Remember right now that structural security, which makes an attack impossible, is worth more than a check that notices it afterwards.
How do you choose your CI/CD tool?
The tool is chosen first according to where your code lives, then according to the deployment mode. The table compares the options covered on this site, each by its own course or guide; none is better in absolute terms, and the same team often combines a CI tool and a GitOps deployment tool. The model learned here holds for all of them.
| Tool | Strengths | Ideal context |
|---|---|---|
| GitHub Actions | Built into GitHub, actions catalogue | Code hosted on GitHub |
| GitLab CI/CD (in French) | Complete solution, self-hostable | Code hosted on GitLab |
| Jenkins | Extensible through plugins, self-hosted | Specific needs, full control |
| Argo CD (in French) | GitOps, rich interface, synchronisation | Continuous deployment on Kubernetes |
| Flux CD (in French) | GitOps through controllers, multi-tenancy | Kubernetes platforms managed through Git |
GitOps: when the cluster pulls its deployments
For deployment on Kubernetes, another approach has taken hold: GitOps.
In the classic model, CI pushes changes by calling kubectl apply or
helm upgrade: the cluster is passive, and a manual change goes undetected. In
the GitOps model, an operator runs in the cluster, reads Git continuously
and reconciles the actual state with what Git describes.
CI then never touches the cluster: it pushes a commit, and the operator deploys. A change made by hand on the cluster is corrected automatically. The table sums up the difference; the GitOps lesson of the "Delivering to environments" module develops it, and the Argo CD and Flux CD trainings put it into practice.
| Approach | Model | Trigger | Drift |
|---|---|---|---|
| CI that pushes | Imperative | CI calls the cluster | Not detected |
| GitOps that pulls | Declarative | The operator reads Git | Detected and corrected |
Key points
- A CI/CD pipeline automates the path from a commit to production, on every change and the same way.
- CI, continuous delivery and continuous deployment are three levels, each including the previous one; start with solid CI.
- A pipeline is made of jobs, stages, runners and artifacts, and keeps the history of every run.
- This course teaches the model before the tool: stages in the repository, a pipeline that orchestrates them, an artifact built once and promoted.
- Practice happens on a local Forgejo forge, with no online account, and each lab is graded on the state left.
- The pipeline is a target: it holds secrets, code and access to production.
- The tool is chosen according to where the code is hosted and the deployment mode; GitOps has the cluster pull its deployments.
FAQ: frequently asked questions
The questions below come up most often among people discovering CI/CD: the difference between the three levels, the stages of a pipeline, the choice of a tool and of a deployment strategy. Each answer sums up what the lessons of the course develop.