Build and release pipelines

Writing code is half the job; getting it safely into users' hands is the other half. A pipeline automates that path — build, test, and ship — so releases are repeatable and boring instead of risky and manual. This is the self-reliance theme at the project scale: you should understand every step that turns a commit into a running service.

The stages

A typical pipeline runs on every push, in order, stopping if any stage fails:

1. Build — compile/transpile, install dependencies, produce an artifact.
2. Test — run the test suite (the testing lesson) and linters.
3. Package — bundle the artifact into something deployable (a binary, a container image, a static bundle).
4. Deploy — push that artifact to an environment.

Because it runs the same steps every time, a pipeline removes "works on my machine" — the build happens in a clean, defined environment, not your laptop.

CI vs CD vs CD

Three terms people blur:

• Continuous Integration (CI): every change is automatically built and tested, early and often, so integration problems surface immediately rather than at the end.
• Continuous Delivery (CD): every change that passes is ready to release at the click of a button — deployment is a decision, not a scramble.
• Continuous Deployment (CD): every change that passes is released automatically, no human gate.

Most teams want solid CI plus continuous delivery, choosing when to actually ship.

Artifacts and reproducibility

The thing the pipeline produces — the artifact — should be built once and promoted unchanged through environments (test → staging → production). Rebuilding per environment invites "it passed in staging but broke in prod." Pin dependencies (the lockfile from the project-shape lesson) so the same inputs always produce the same output.

Where to go next

A pipeline can deploy — but how, exactly, without downtime or risk? Next: deployment strategies.