Course outline · 0% complete

0/29 lessons0%

Course overview →

Continuous Integration: Tests on Every Change

lesson 6-3 · ~10 min · 19/29

The safety net only works if it runs

Everything in this course assumes the tests actually get run — and humans forget. You make a "tiny" change at 6 pm, skip the suite because you are sure, and ship the regression the tests would have caught. Every team learns this the painful way, which is why they stopped trusting memory and gave the job to a machine.

Continuous integration (CI) is the practice of having a server automatically run the whole test suite on every proposed change, before that change is allowed to join the shared codebase. The workflow at nearly every software company today:

  1. you finish a change and propose it to the team
  2. the CI server takes a fresh copy of the codebase plus your change and runs every test on a clean machine
  3. green: the change may merge into the shared code. Red: the change is blocked until fixed

Two consequences matter. First, "it works on my machine" stops being an argument, because the clean machine is the referee. Second, the pyramid from lesson 6-1 turns into an economic constraint: CI runs on every change, so a slow suite taxes every engineer on the team many times a day.

Code exercise · python

Run this miniature CI gate. ci_gate plays the server's role: run every test, then either bless the change or block the merge. The real service does exactly this, plus fetching your change and setting up the clean machine.

Quiz

Your change passes every test on your laptop, but CI reports one failure and blocks the merge. What is the correct reading?

Code exercise · python

Your turn. A teammate's change to format_price just hit the CI gate and got blocked — run it to see the red report. The spec wants prices with exactly two decimals, like $5.00. Fix format_price using the :.2f format spec so the gate flips to green.

Problem

Spell it out: what does the acronym CI stand for?