What a Deployment Pipeline Looks Like
A deployment pipeline is the assembly line that turns a commit into a running release.
Every reliable deployment follows the same shape: build once, test thoroughly, then promote the exact same artifact through environments until it reaches production. This lesson walks the stages and explains why building once and promoting matters.
The core stages
- Build: compile or package the application into an immutable artifact.
- Test: unit, integration, and sometimes end-to-end checks against that artifact.
- Package: produce a versioned, reusable output (container image, zip, bundle).
- Promote: move the same artifact through staging to production.
Build once, promote everywhere
A common mistake is rebuilding the app for each environment. Instead, build a single immutable artifact and promote that exact artifact forward. This guarantees what you tested in staging is byte-for-byte what runs in production. Configuration, not the binary, changes per environment.
Artifacts flow forward
Pass the built artifact between jobs with actions/upload-artifact and download-artifact, or push a versioned image to a registry. Downstream jobs consume it rather than rebuilding:
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci && npm run build
- uses: actions/upload-artifact@v4
with:
name: app-bundle
path: dist/
deploy:
needs: build
runs-on: ubuntu-latest
steps:
- uses: actions/download-artifact@v4
with: { name: app-bundle }Quality gates between stages
Each promotion is a gate: tests must pass, security scans must be clean, and (for delivery) a human may approve. A failed gate stops the artifact from moving forward, so problems are caught before production.
Key takeaways
- A pipeline moves a commit through build, test, package, and promote stages.
- Build one immutable artifact and promote it; only configuration changes per environment.
- Gates between stages stop bad changes from reaching production.