Testing and shipping every change (CI/CD)

Friday afternoon

At 4pm on a Friday, Priya copies a change to the shop's server by hand. She forgets one file.

The checkout page breaks. Nobody notices until Monday. The shop loses a weekend of orders.

Most teams no longer ship changes by hand. A machine runs the same checks every time, and it never forgets a file.

By the end of this lesson

Note

I can describe a pipeline that tests and ships code.

Key words

Word	What it means
Pipeline	steps a machine runs on every change
Stage	one step of a pipeline
Continuous integration (CI)	testing every change as soon as it is pushed
Continuous delivery (CD)	shipping every tested change the same safe way
Staging	a copy of the live system for a last check
Rollback	going back to the last version that worked

The cells students fill in are left blank in this preview.

A pipeline runs the same steps every time

A pipeline starts by itself whenever someone pushes a change. It runs its stages in order.

If a stage fails, the pipeline stops. Nothing after it runs, and the change does not ship.

Testing every change straight away is continuous integration. Run the pipeline below, then break the test as the comment says.

Run a small pipeline

Code: bash

mkdir -p shop && cd shop
printf '24\n' > total.txt   # the code's answer for a 20 pound item plus 4 pounds VAT

check_style() { echo "Stage 1: check style ... ok"; }
run_tests() {
  echo "Stage 2: run tests"
  if [ "$(cat total.txt)" = "24" ]; then
    echo "  test basket total ... passed"
  else
    echo "  test basket total ... FAILED"
    return 1
  fi
}
build() { echo "Stage 3: build image orders:1.5 ... ok"; }
deploy() { echo "Stage 4: deploy to live ... ok"; }

set -e   # stop at the first stage that fails
check_style
run_tests
build
deploy
echo "Pipeline passed: the change is live"

# Change 24 to 25 on the second line, then press Run. Which stages still run?

A common mistake

Warning

Many people think a green pipeline means the code has no bugs. It does not. Green means every test you wrote passed. A case nobody tested can still be wrong, so a bug found later becomes a new test.

The pipeline is a file in the repository

Nobody clicks through the stages. The team writes them in a file kept with the code, often in YAML.

Each step has a name and a command to run. A change to the pipeline is reviewed like any other change.

Below, Bash writes a pipeline file and reads it. Make the change in the last comment.

Read a pipeline file

Code: bash

mkdir -p shop && cd shop
cat > pipeline.yml <<'EOF'
on: push
jobs:
  ship:
    steps:
      - name: Check style
        run: ruff check .
      - name: Run tests
        run: pytest
      - name: Build image
        run: docker build -t orders:1.5 .
      - name: Deploy to staging
        run: ./deploy.sh staging
EOF

# The names of the stages, in order
grep "name:" pipeline.yml

# How many commands the pipeline runs
grep -c "run:" pipeline.yml

# Add a step named "Deploy to live" that runs ./deploy.sh live, then run again.

Staging first, then live

Continuous delivery ships every change the same way. A tested image goes to staging first.

Staging is a copy of the live system with no real customers. The team checks it there.

Then the same image goes live. If live goes wrong, a rollback puts back the last image that worked.