Skip to main content
No code reaches production without passing every gate below. No gate can be bypassed by an individual contributor.

​
Pull request gates

Every PR to master must pass:
1

Linting

RuboCop (backend), ESLint + TypeScript strict (frontend), terraform fmt + terraform validate.
2

Tests

Backend: parallel_rspec across 4 shards. Frontend: Vitest across 4 shards. E2E: Playwright smoke tests. 90% / 80% coverage minimums enforced.
3

Security scans

Brakeman (SAST), bundler-audit, npm audit, Trivy (Terraform), gitleaks, license_finder. All blocking on medium+ severity.
4

Type check

tsc --build for frontend; RBS / Sorbet not yet enabled.
5

OpenAPI drift check

If request specs changed, the OpenAPI spec must be regenerated and the TypeScript types migrated.
6

Code review

At least one approving review from someone other than the author. Security-sensitive changes (policies, auth, encryption, PHI) require an additional reviewer.

​
Deployment pipeline

1

Build

On merge to master, GitHub Actions builds Docker images for backend and frontend. Images are tagged with the full commit SHA.
2

Push

Images are pushed to GCP Artifact Registry via Workload Identity Federation — no long-lived keys.
3

Migrate

A Cloud Run migration job runs database migrations before the new image is promoted.
4

Deploy

Cloud Run deploys the new image with a gradual rollout. Health checks must pass before 100% traffic.
5

Verify

Smoke tests hit the live deployment. Rollback is automatic on failure.

​
Strong migrations

The strong_migrations gem enforces safe migration practices:
  • No removing columns without safety_assured and a compatibility window.
  • Concurrent index creation for large tables.
  • Backfills must be separated from schema changes.
  • Any unsafe migration raises StrongMigrations::UnsafeMigration in development.

​
Rollback

  • Cloud Run revision rollback — any previous revision can be promoted via one command.
  • Database rollback — migrations are forward-compatible where possible; destructive rollbacks require a manual runbook and approval.
  • Config rollback — Terraform state is versioned; any change can be rolled back via re-apply of the previous plan.

​
Segregation of duties

  • Developers have read access to production logs and metrics (via GCP IAM) but no direct write access to the database or production Secret Manager values.
  • Deployment is performed by the CI/CD pipeline under a deploy-specific service account — no humans hold its credentials.
  • Break-glass access for production incidents is granted just-in-time via a documented procedure and audit-logged.

​
Infrastructure changes

Terraform applies go through the same PR process — plan review in the PR, apply after merge. Applies are performed via Cloud Build (regional bucket) and the deploy service account.

​
Artifact signing (planned)

Image signing with Sigstore/cosign and verification at deploy time is on the roadmap — target Q3 2026.