From CI Checks to a Coordinated Production Release

Scopebase had CI before it had a production release pipeline.

Pull requests and pushes to main ran formatting, lint, type checks, and a build. That caught code problems. It didn't answer a different question: are the web app and background worker, built from the same change, ready to run together in production?

I had to make that question part of the release process. The new GitHub Actions workflow is configured to stage the web app, verify release inputs, package the worker, and coordinate their cutover. The workflow configuration is real. A successful production run is a separate claim, and I won't make it without a completed run and its evidence.

CI answers a smaller question

The existing checks workflow runs for pull requests and pushes to main. It installs the locked dependencies and runs formatting, lint, type checks, and the build.

Those checks are necessary, but a green build does not validate the inputs that Scopebase requires to enable reviews. It also doesn't prove that a worker artifact corresponds to the web deployment that will receive its results. A deployment can be healthy as a website while its worker is old, missing configuration, or unable to claim work.

So the release workflow treats CI as one part of release readiness. The production release starts on a push to main; it can also be dispatched manually for recovery. Direct Vercel Git deployments from main are disabled so this workflow owns production promotion.

Prepare the pieces in parallel

The workflow starts three jobs for the same commit. One stages a web deployment and records its URL. Another checks release inputs and produces a verification artifact. The third builds and packages the worker with its release identity.

Parallel work saves time, but it creates a matching problem. The release job must not combine a web deployment from one commit with a worker artifact from another, or verification from an earlier retry. So the artifact names and join checks bind them to the same commit, workflow run, and attempt. If one output is missing or mismatched, the release stops.

Evidence follows the release

The verification job checks the current release inputs against an operator-approved model quality report and its binding. It also captures checks and input hashes. It does not run a live model evaluation or create an approval on its own.

Once the job outputs match, the workflow gathers operational evidence for the staged deployment, migrations, permissions, and other release inputs. It generates an attestation tied to the commit, then stages another web deployment with that evidence attached. The worker package receives matching release evidence through its private runtime configuration.

That second web build is a deliberate cost. The first staged deployment gives the workflow something concrete to verify. Only after it has collected and checked the matching evidence can it prepare the final deployment that carries the attestation.

Cut over as one operation

The release controller coordinates the web deployment and worker. It pauses review admission before promotion, then checks the exact active web deployment and worker before resuming reviews.

If readiness is uncertain, the workflow keeps admission closed. If a release is interrupted, recovery is tied to the saved cutover target. A newer commit can't silently replace that target halfway through recovery. This is more involved than asking a platform to deploy on every push, but it gives the system one place to decide whether both halves of the release are ready.

Configuration is not evidence of a successful release

The release design is still marked in progress, and the workflow being configured doesn't tell me whether it has completed successfully against production. Before saying that it has, I need a completed workflow run and its retained evidence. Until then, the accurate statement is narrower: Scopebase now has a configured path from a main commit to a coordinated, evidence-checked release.

That distinction is useful beyond this project. CI tells me that a set of code checks passed. A release process has to show which artifacts those checks belong to, what operational facts were verified, and what the system did when readiness was unclear. Scopebase's pipeline is designed to make those answers travel with each release.