Introduction
The vocabulary of continuous integration, and the criteria for choosing what to automate.
On a repository without continuous integration, quality rests on a sentence no one ever wrote down: "Before you push, run the tests." It holds for a few weeks. Then one Friday evening, someone pushes a one-line fix without running them, because one line can't break anything. On Monday, the main branch is red, three people have already pulled from it, and it takes half a day to tell the faulty commit apart from the commits that merely built on top of it. The real cost isn't the missing test; it's the delay between the mistake and its discovery.
Continuous integration attacks exactly that delay. It moves verification from the developer's machine to a neutral machine that runs it on every push, without exception, without depending on anyone's discipline. It provides three things that no team convention can: reproducibility, because the environment is described in a versioned file rather than on a workstation; traceability, because every run leaves a dated log tied to a specific commit; and enforcement, because a red result can block a merge, something a verbal reminder has never done.
Comments
Comments are powered by GitHub Discussions
Sign in with GitHub to join the discussion