What continuous integration actually means

Continuous integration is a habit before it is a tool: everybody merges their work into the shared branch frequently, at least daily, and every merge is automatically built and tested.

The problem it solves is the long lived branch. Two developers work separately for three weeks, both change the same areas, and merging becomes a week of pain in which working code becomes broken code. Merging daily makes each merge small enough to be boring, which is the goal.

Continuous delivery means the main branch is always in a state that could be released. Continuous deployment means it actually is released, automatically. The second is a business decision and not everyone should make it.

A pipeline is a sequence that runs on every push. Install dependencies, run the linter, run the tests, build, and only if everything passes, deploy.

Fail fast. Put the quick checks first. A linting error should fail in twenty seconds, not after a six minute test suite.

The rule that makes it work: a red pipeline is stopped immediately, by whoever broke it, before anything else. A team that tolerates a broken main branch for a day has stopped doing continuous integration and has only kept the tooling. Everyone then learns to ignore the failure notifications, and at that point the pipeline is theatre.

Start small. A pipeline that only runs your tests on every push is already most of the value, and you can add steps later.