Capstone: reading a real deploy.yml as a release-engineering case study

The workflow under review

Here is the shape of the pipeline, condensed to the load-bearing parts:

name: build-deploy
on:
  push:
    branches: [main]

concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: true        # a newer push aborts an in-flight deploy

permissions:
  contents: read

jobs:
  build-deploy:                    # one job: plan → build → lint → deploy
    runs-on: ubuntu-latest
    timeout-minutes: 90
    steps:
      - uses: actions/checkout@v4
      - uses: actions/cache@v4      # state lives here, not in artifacts
        with:
          key: build-${{ hashFiles('content-hash') }}
          path: dist/
      - run: bun install --frozen-lockfile
      - run: bun run build          # full render ~12 min (incremental shorter)
      - run: cat dist/lint-report.json   # build-time linter gate
      - run: ./deploy.sh dist/       # upload static output to the CDN/Pages host

What it does well, in this unit’s vocabulary:

• concurrency with cancel-in-progress: true keyed on the ref means a newer push to main cancels an older, still-running deploy of the same branch. You never get two deploys racing to publish, and you never waste a 12-minute build on a commit that has already been superseded. This is the right default for a single-target static deploy where only the latest state matters.
• A single artifact-free job is the scar tissue from the Hook: plan, build, lint, and deploy run in one job and pass state through actions/cache (a separate quota from artifacts), so there is no 420 MB hand-off to wedge. Keeping the whole pipeline in one job also means there is no inter-job artifact to expire or corrupt — the cost is that the steps cannot scale out, which for a ~12-minute build is an acceptable trade.
• permissions: contents: read is least privilege: the job’s token can read the repo and nothing else, so a compromised step cannot push commits or publish packages.
• The build-time linter (lint-report.json) is a release gate inside the build — content that violates the rules fails the run before anything ships.

Judge it against the release-engineering bar

When you read any pipeline, try to separate two questions: “does this deploy correctly?” and “does this govern a release?” Most pipelines answer yes to the first and no to the second. The workflow is operationally sound, but read it against the four pillars of this unit and the gaps are clear — and instructive, because they are the difference between “deploys a static site” and “governs a release.”

• Versioning and tags: this pipeline deploys on every push to main with no version, no tag, and no immutable ref. For a static site that is publishing latest-wins, that is a defensible choice — but it means there is no named release to point at, and “roll back to the last good version” has nothing to name. The mitigation that fits this design is the deploy host’s own immutable deployment history (each upload is a distinct, addressable deployment you can instantly re-promote), which substitutes for a git tag as the reversibility anchor.
• Changelog and release record: there is no generated changelog and no release object, so “what changed in this deploy” is answerable only by reading the commit that triggered it. Acceptable for an internal site; a gap the moment external consumers or auditors need a per-release record.
• Environments and gates: the deploy runs straight to production on push with no environment, no required reviewer, and no wait timer. Every merged commit ships instantly with no human at release time and no soak. This is the single biggest gap against the unit: for anything beyond a low-stakes static site, you would put the deploy behind a production environment with a required reviewer and a short wait timer, and likely split build (on push) from deploy (gated).
• Reversibility: there is no explicit rollback path in the workflow. Recovery depends entirely on the deploy host’s ability to re-promote a previous deployment. That works for a static CDN host, but it is implicit — a senior would make “re-deploy the previous known-good deployment” an explicit, tested, one-command path rather than a property they are assuming the platform provides.