CI/CD Introduction

CI: Automatically Verifying Every Change. Continuous Integration means every code change (typically, every push or pull request) automatically triggers an equivalent set of checks — running tests, linting, type-checking — catching a broken change before it's merged, rather than relying on a human remembering to run these checks manually every time.

CD: Automatically Deploying a Verified Change. Continuous Deployment (or the more conservative Continuous Delivery, requiring a manual approval step) extends CI by automatically deploying a change that passes all checks — reducing the manual, error-prone, and often infrequent process of a human manually building and pushing a deploy.

A Typical Node.js CI Pipeline's Essential Steps. A reasonably complete CI pipeline for a Node.js project runs, in order: install dependencies (via npm ci, not npm install, for reproducibility), lint, type-check (if using TypeScript), run the test suite, and build — failing fast at the first failing step rather than continuing to run subsequent, now-pointless steps.

Caching Dependencies to Speed Up CI Runs. Re-downloading and reinstalling every dependency from scratch on every single CI run is slow and wasteful — most CI platforms support caching node_modules (or npm's own cache) keyed by the lockfile's hash, so a run with unchanged dependencies skips the slow install step almost entirely.

Environment-Specific Secrets in CI/CD. A CI/CD pipeline needing real secrets (a deploy credential, an API key for an integration test) should source them from the CI platform's own secrets management feature (GitHub Actions Secrets, GitLab CI/CD variables) — never hardcoded in the pipeline configuration file itself, which is typically committed to version control.

Branch Protection: Requiring CI to Pass Before Merge. Configuring the repository to require CI checks to pass before a pull request can be merged — a "branch protection rule" — turns CI from an informational signal into an actual enforced gate, preventing a genuinely broken change from ever reaching the main branch in the first place.

Separate Pipelines for Different Environments. A mature CI/CD setup typically distinguishes pipeline behavior by branch or trigger — every PR runs the full CI suite, merging to a staging branch triggers a staging deploy, and merging to main (perhaps requiring an additional manual approval) triggers a production deploy — rather than treating every branch identically.

Why is npm ci used in a CI pipeline's install step, rather than npm install?

• →npm ci installs strictly from the lockfile and fails on any mismatch, guaranteeing a reproducible install rather than silently drifting
• →npm ci is always faster than npm install, regardless of caching