Deployment And Verification

Deployment And Verification covers the boundary between repository-controlled static output and the site served by Cloudflare Pages.

Purpose And Ownership

The project deliberately separates three operations:

  1. Read-only validation for pull requests and pushes.
  2. Automatic release synchronization and production deployment after a successful push validation on main, with manual redeployment available.
  3. Optional hosted diagnostics, rollback rehearsal, and emergency restoration.

This area owns Cloudflare credentials, production concurrency, static uploads, hosted reports, and rollback operations. It does not own canonical evidence content, release identity, page meaning, or permanent data storage.

Concepts In This Area

  • Cloudflare Pages Deployment explains read-only validation, trusted release synchronization, production publication, credentials, and failure behavior.
  • Hosted Release Verification explains the separate diagnostic that compares a hosted surface with committed release state.

Normal Flow

  1. A push or pull request runs type checking, tests, the production build, sitemap validation, Playwright, and Axe.
  2. Validation cannot create commits or contact Cloudflare.
  3. A successful push validation on main automatically starts Deploy application for that exact validated commit. A maintainer may also dispatch it manually from main.
  4. The deployment workflow synchronizes the active release, creates and pushes a generated-state commit only when public bytes changed, reproduces the result, and uploads it with the pinned Wrangler CLI.
  5. Hosted verification may be run separately when release-level operational evidence is needed.

A failed validation does not change production. A failed hosted diagnostic does not trigger deployment or rollback.

Recovery Boundary

Routine deployment does not automatically choose or restore another Cloudflare deployment. Rollback rehearsal remains an explicit confirmed workflow, and emergency restoration remains a deliberate maintainer procedure.

Preview deployments never qualify as restoration targets. Cloudflare deployment identity remains separate from VyDex release identity.

Invariants

  • Cloudflare Pages is the production host; Workers and workers.dev are not alternatives.
  • Validation has read-only repository permissions and no deployment credentials.
  • Production deployment is automatic after successful main validation and remains manually dispatchable from main.
  • Deployment and rollback rehearsal share one non-cancelling production concurrency group.
  • Deployment may create one non-forced bot commit containing only verified generated/release-data/ changes; unchanged public output creates no commit.
  • Hosted verification uses stable semantic release markers rather than exact marketing copy.
  • Operational reports and Cloudflare history never become canonical evidence records.

Implementation Landmarks

  • .github/workflows/validate-application.yml
  • .github/workflows/deploy-application.yml
  • .github/workflows/rehearse-production-rollback.yml
  • scripts/deployment/
  • src/release/stage-one-hosted-verification/
  • src/adapters/cloudflare-pages-api/