A Pragmatic Pipeline Template Teams Can Copy

All the theory in this series is only useful if it turns into a pipeline teams actually run. This post pulls it together into a pragmatic template: a layered CI/CD pipeline that any team can copy and adapt — deterministic build, fast checks, vulnerability scan, immutable artifact, and a gated deploy. It is the shape that all the earlier posts recommend, in one place.

The layering principle

The template splits work into stages that get progressively more expensive and more rigorous:

• Commit time: lint, typecheck, fast unit tests (seconds).
• Build: produce a deterministic, immutable artifact (a minute or two).
• Scan: audit dependencies and the image for vulnerabilities.
• Deploy: promote the artifact to a target, gated by environment and approval.

Layering matters because developers get the fast feedback loop on every commit, while the heavy validation runs only when it earns its cost. If every commit had to wait on the full integration and deploy, the fast loop would die.

The workflow files

Here is a compact representation of the pull-request and merge pipeline, expressed as two workflows:

name: verify
on: [pull_request]
jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: npm }
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --runInBand --bail
      - run: npm run typecheck

name: release
on:
  push:
    branches: [main]
jobs:
  build-and-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: docker build -t app:latest .
      - run: trivy image --exit-code 1 --severity HIGH,CRITICAL app:latest
      - run: docker push app:latest
      - run: ./scripts/record-digest
  deploy:
    needs: build-and-scan
    runs-on: ubuntu-latest
    environment: production
    steps:
      - run: ./scripts/promote --from staging --to production
      - run: ./scripts/smoke --env production

Note the release job only runs on main (the trunk), uses the build-once artifact, scans it, and deploys through a promote step into a protected environment. That is the discipline from the whole series in one file pair.

Branch protection and the merge gate

The template assumes branch protection matches: main requires the verify workflow, builds no longer than a handful of minutes, and merges are up-to-date. Wire the numbers into the protection config so the pipeline and the branch rules agree, exactly as the branch-protection post urges. The verify workflow is the fast consumer gate; the release workflow is the production gate.

Adapting the template to your stack

Swap node for the language you use — python, go, or a compiled stack — and npm ci for your lockfile install. The shapes stay identical: a fast verify job, a build-and-scan release job, and a promote-plus-smoke deploy job. For a single small service, you can even collapse release and deploy; for a monorepo or microservices, replicate the template per service and namespace the artifacts. Start with one service, prove the shape, then copy it.

Keeping it honest

The template earns nothing on its own; what matters is the discipline wrapped around it — keep the fast loop fast, never let the scan go red silently, expire exceptions, and rehearse rollbacks. When the pipeline is stable, the artifact promotes cleanly, and deployments are boring, you have reached the end state this entire series has been building toward: software that moves quickly and safely, measured and rehearsed, not improvised.

Takeaway: copy this layered pipeline — verify on commit, build-and-scan on merge, promote and smoke on deploy — and adapt the stages to your stack and environments. Run it all against services hosted on a Netbay VPS from Lucknow DC01, instant to provision at netbayhosts.in, and your delivery gets measurably safer and faster.