Deployment Pipeline
also called CD Pipeline, Build Pipeline
The automated path a commit travels from source to production, where every stage is a chance to reject the change and no stage can be skipped.
The pipeline is not a build script with extra steps. Its defining property is that a commit enters once and either reaches production or is rejected with a reason — there is no side door, no manual copy of a binary onto a server, no "just this once".
Two rules make it real. The artifact is built once and promoted unchanged through every environment; if staging and production build separately, you have tested something you are not shipping. And every stage is ordered by cost and confidence: fast cheap checks first, so the majority of failures are found in the first two minutes rather than after a forty-minute integration suite.
The design question is where to put each check, and the answer follows from what it costs to run and what it costs to miss. A linter belongs in the first stage. A full performance test belongs after the artifact exists, and probably not on every commit.
The health metric is not "does it pass" but how long a green commit takes to reach production, and whether anybody is tempted to bypass it. A pipeline people route around has already failed.