CI/CD Pipelines

Continuous integration means everyone merges to a shared branch frequently and an automated build verifies each merge. The value is the frequency: integrating daily makes conflicts small, and the build is what makes daily integration safe.

Continuous delivery versus continuous deployment. Delivery means every passing build is releasable — the remaining step is a human choosing to press the button. Deployment removes the button: passing the pipeline ships to production. They are constantly used interchangeably and the distinction is exactly what an interviewer is checking.

A pipeline is a sequence of stages, each a gate. Typically: install dependencies, lint, typecheck, unit tests, build, integration tests, deploy to a staging environment, smoke test, deploy to production. Order matters — run the cheap, fast checks first so a formatting error fails in twenty seconds rather than after a fifteen-minute test run. This is fail fast applied to CI.

A build artifact should be built once and promoted. Rebuilding per environment means the thing you tested is not the thing you shipped. Build one artifact, then move it through environments with configuration supplied externally.

Deployment strategies. Blue-green runs two identical environments and switches traffic, making rollback a switch back. Canary sends a small percentage of traffic to the new version and watches error rates before widening. Rolling replaces instances gradually. All three exist so that a bad release affects some users briefly rather than all users indefinitely.

Caching and matrix builds are the two levers on pipeline speed: cache dependencies between runs, and run independent jobs in parallel rather than in sequence.

DORA metrics — deployment frequency, lead time for changes, change failure rate, and time to restore — are the standard way delivery performance gets measured.