CI/CD for a Web Application

A small team ships a web app — a Node frontend and a Go service living in one monorepo — to a handful of paying customers. Every change goes through a PR, merging to main should put it in front of internal testers within minutes, and a tagged release should promote it to production once a human approves. The team has exactly one platform engineer, so the pipeline has to run itself: no manual deploy steps, no long-lived cloud keys sitting in a secrets store waiting to leak.

The design choices here are about trust and identity as much as automation. What does each stage gate? Which credential can reach production, and for how long? The decisions that matter — build once and promote the same artifact, scope production secrets to an approved environment, and authenticate to the cloud with short-lived OIDC tokens — are the ones that keep a fast pipeline from becoming a fast way to ship the wrong bits or leak a key.

The PR Gate

Every pull_request runs the same checks: lint, type-check, unit tests, and a build. The point of the gate is that nothing reaches main without passing it, enforced by a required status check in branch protection. The one piece teams forget is concurrency — without it, a developer who force-pushes three times queues three full builds, and the runners spend their day on stale commits.

on: pull_request
concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint && npm run typecheck && npm test

Build Once, Promote the Same Artifact

The cardinal rule of a deploy pipeline is that the artifact you tested is the artifact you ship. Build the container image one time, push it to a registry, and refer to it everywhere by its immutable digest — not a mutable tag like latest that can point at different bytes tomorrow. Staging deploys that digest; production deploys the same digest. The moment you rebuild per environment, "it passed in staging" stops meaning anything, because production is running a different build.

Promotion is therefore a deploy of a known digest, never a fresh build:

      - run: |
          IMAGE=registry.example.com/app@${{ needs.build.outputs.digest }}
          deploy --image "$IMAGE" --env production

Environments and Protection Rules

Staging deploys automatically on merge to main. Production is a GitHub Environment with required reviewers and a wait timer, and — this is the part that does the security work — the production deploy credentials are scoped to that environment. A workflow job that does not target the production environment cannot read its secrets at all, so a careless or malicious job elsewhere in the repo has no path to the production credential.

  deploy-prod:
    needs: build
    environment: production   # gates secrets behind required reviewers
    runs-on: ubuntu-latest
    steps:
      - run: deploy --image "registry.example.com/app@${{ needs.build.outputs.digest }}"

OIDC Instead of Stored Keys

The deploy job needs to authenticate to the cloud, and the lazy way is a long-lived access key stored as a repo secret. That key is a standing liability: it works from anywhere, never expires on its own, and one leak compromises the whole account. OIDC federation replaces it. The job requests id-token: write, the runner mints a short-lived token signed by GitHub, and a cloud-side trust policy accepts it only when it comes from this repo and this environment. There is no static credential to leak, and the token dies in minutes.

    permissions:
      id-token: write
      contents: read
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123:role/deploy
          aws-region: us-east-1   # short-lived token, no stored key

Rollback and the Health Gate

Because every deploy is a digest, rollback is trivial: redeploy the previous known-good digest. There is no reverting commits and rebuilding under pressure — the old artifact still exists in the registry, and pointing production back at it is one command. The other half is not declaring victory when the pipeline goes green. A passing pipeline means the rollout command succeeded, not that the app is healthy. A post-deploy smoke test against the live environment is what turns "deployed" into "working," and its failure is what triggers the rollback.

Speed Budget

A pipeline slower than about five minutes gets routed around — developers merge without waiting, or push "fix CI" commits blindly. Dependency caching and build-layer caching keep PR feedback fast enough that the gate stays a gate rather than an obstacle people learn to ignore.