Continuous integration and deployment: principles, pipeline, environments

Objective

Understand why teams automate their tests and their production releases, what the acronyms CI and CD cover exactly, how a pipeline is structured, and what environments are for. You will then write your first pipeline… in plain shell, to see clearly what a tool such as GitHub Actions or GitLab CI automates.

Key points

• Continuous integration (CI): every pushed change is built and tested automatically, several times a day, to detect problems immediately.
• Continuous delivery: every version that passes CI is ready to go to production; the production release remains a human click.
• Continuous deployment: every version that passes all the checks goes to production automatically.
• A pipeline chains steps (lint, tests, build, deployment); the first one that fails stops everything.
• Environments (development, staging, production) let you validate a version before it reaches customers.
• Core principle: you build only once and deploy the same artifact everywhere.

1. The problem: "it works on my machine"

At the agency Atlas Web (Casablanca), before automation, a production release looked like this:

• on Friday evening, Youssef merges three weeks of work by four people;
• nobody has run all the tests: some have been failing for ten days;
• he builds the site on his workstation (with his version of Node.js), then copies the files to the server over FTP;
• a client's website goes down on Saturday; nobody knows which change caused it.

Continuous integration and deployment solve these problems with three ideas:

2. CI, continuous delivery, continuous deployment

                         Continuous integration (CI)
            ┌──────────────────────────────────────────────┐
  push  →   │ fetch the code → lint → tests → build        │ → artifact
            └──────────────────────────────────────────────┘
                                                              │
     Continuous delivery: automatic deployment to staging,    │
     to production on a human decision (button)  ─────────────┤
                                                              │
     Continuous deployment: everything is automatic up to     │
     production, if all checks are green  ────────────────────┘

In practice, people often say "CI/CD" for the whole thing. An agency like Atlas Web typically does continuous delivery: every merge into main goes automatically to staging, and the project manager triggers the production release after the client's approval.

3. Anatomy of a pipeline

A pipeline is split into stages that contain jobs. Jobs in the same stage can run in parallel; stages run in order.

  "check" stage         "test" stage            "build" stage           "deploy" stage
  ┌──────────┐            ┌──────────────┐        ┌──────────────┐        ┌──────────────┐
  │ lint     │            │ tests Node 20│        │ Docker image │        │ staging      │
  │ format   │   ───→     │ tests Node 22│  ───→  │ archive      │  ───→  │ production   │
  └──────────┘            └──────────────┘        └──────────────┘        │ (manual)     │
                                                                          └──────────────┘

The pipeline runs on a runner (or executor): a machine, often a fresh virtual machine or container, provided by GitHub or GitLab, or installed on your own servers. Because it starts from scratch every time, "it works on my machine" disappears.

The good properties of a pipeline

• Fast: less than 10 minutes for the main feedback; beyond that, developers stop waiting for the result.
• Reliable: a test that fails at random (flaky) destroys trust; you fix it or remove it.
• Versioned: the pipeline is a file in the repository (.github/workflows/*.yml, .gitlab-ci.yml), reviewed in pull requests like the code.
• Red = priority: when main is broken, the team fixes it before moving on.

4. Environments

Rules that prevent disasters:

• The same artifact moves from staging to production: you do not rebuild between the two, otherwise what you validated is not what you deploy.
• Only the configuration changes from one environment to another (database address, API keys), through variables and secrets specific to each environment.
• Production is protected: deployment restricted to certain branches, mandatory approval, secrets that other jobs cannot access.
• You can always roll back to the previous version (lesson 3.2).

5. The tool landscape

Levels 1 and 2 of this course cover GitHub Actions, then GitLab CI. Once you understand the principles, moving from one to the other is mostly a matter of vocabulary.

6. A pipeline by hand, to understand

Before handing the work to a platform, let's write the same sequence in shell. This is exactly what a runner will do: commands, in order, stopping at the first error.

#!/bin/sh
# scripts/pipeline.sh — local pipeline for the Atlas storefront
set -e                      # stop at the first command that fails

echo "== lint"
npm run lint

echo "== tests"
npm test

echo "== build"
mkdir -p dist
tar -czf dist/vitrine.tar.gz package.json src
echo "Artefact prêt : dist/vitrine.tar.gz"

chmod +x scripts/pipeline.sh
./scripts/pipeline.sh
echo "code : $?"            # 0 = green pipeline; anything else = red

set -e is the key: without it, the script would continue after a failed test and produce a broken artifact. CI platforms apply the same rule: a command that returns a non-zero code makes the job fail.

You can even connect this pipeline to Git with a pre-push hook (Git course, lesson 3.2): the push is rejected if the pipeline fails. This is useful, but it stays on your workstation and can be bypassed with --no-verify. Real CI runs on the server, for everyone, on every push.

7. Measuring: the four metrics

To know whether your delivery chain is improving, teams often track four metrics (called "DORA" metrics):

Good CI/CD raises the first two and lowers the last two at the same time: you deliver more often and more safely, because each delivery is small.

8. Where to start in an existing team

There is no need to automate everything at once. Here is the plan Atlas Web followed, over about a month:

Only then come optimization (cache, parallelism), advanced security (OIDC, signatures, level 4) and, if the team wants it, full continuous deployment.

Two tips to make this transition succeed:

• Measure before and after: the average duration of a production release, the number of incidents per month. These figures convince better than a speech.
• Keep the pipeline simple and readable: a YAML file that the whole team understands is better than an overcomplicated machine that only one person can repair.

Common pitfalls

• Automating chaos: without automated tests, a pipeline only deploys bugs faster. Start with a few tests on the critical functions (price calculation, payment).
• Rebuilding for production what was validated in staging: it is no longer the same artifact.
• A 40-minute pipeline: developers push less often and work around CI. Parallelize and use caching (lesson 1.3).
• Ignoring a red pipeline "because this test always fails": fix it or delete it, but do not get used to red.

Lab

In the Node.js project /root/vitrine (already in Git, with a test and a lint), you build a local pipeline:

1. scripts/pipeline.sh: lint then tests, stopping at the first error;
2. a build step that produces the artifact dist/vitrine.tar.gz, only if everything is green;
3. a commit of the script, without the artifact;
4. a pre-push hook that runs the pipeline before every push.

The checks deliberately break a test in a copy of the project to make sure that your pipeline really turns red.

Quiz

1. What is the difference between continuous delivery and continuous deployment?
2. Why does a pipeline stop at the first failed step?
3. What is a runner, and why does it start from a fresh machine?
4. Why must you deploy to production the same artifact as the one validated in staging?
5. What does set -e do in a pipeline script?

Reference sources: GitHub Docs (CC BY 4.0) and GitLab Docs (CC BY-SA 4.0). Original MasterLinux text.