Skip to content

Deploying changes to production

How deployment works

When CC pushes code to GitHub, the frontend (BMS and client portal) deploys automatically via Vercel. No action needed from you.

But two things do not deploy automatically:

  • Database migrations (new tables, columns, constraints, seed data)
  • Edge Functions (Supabase serverless functions)

If you skip deploying these, the frontend will be running new code against a stale database or stale Edge Functions. Things will break.

The simple version

After a CC session where database or Edge Function changes were made, tell CC:

"commit, push and make live"

CC will commit, push to GitHub, and then run the appropriate deploy scripts. You don't need to run anything manually unless CC can't do it for some reason.

What CC does behind the scenes

For database migrations

CC runs ./scripts/deploy-prod.ps1, which:

  1. Links the Supabase CLI to the production project
  2. Runs supabase db push to apply any pending migration files
  3. Shows the migration list so you can verify
  4. Switches back to the dev project
  5. Checks _project-state.md for stale "not yet pushed to prod" entries

For Edge Functions

CC runs ./scripts/deploy-edge-prod.ps1 <function-names>, which:

  1. Deploys each named function to production (with --no-verify-jwt)
  2. Updates the Edge Function deploy manifest (docs/admin/audit/edge-function-deploy-manifest.json) with the new file hashes and today's date

The deploy manifest is how the nightly health check knows whether prod is in sync with the repo.

When to say "make live"

You need to say "make live" after:

  • Any session where CC created or modified migration files (supabase/migrations/)
  • Any session where CC created or modified Edge Functions (supabase/functions/)
  • CC is instructed to remind you when this applies — look for it in the report-back

You do not need to say "make live" for:

  • Frontend-only changes (components, pages, styles) — Vercel handles these automatically
  • Changes only on the dev branch that aren't ready for production yet

Safety nets

If you forget, the system will catch it:

  • Nightly health check runs at 1pm AEST every day. It compares local migrations and Edge Function hashes against production. If anything is out of sync, it creates a GitHub Issue (labelled health-check) and you'll get an email notification.
  • CC checks at session start — CC is instructed to check _project-state.md for stale "not yet deployed" entries when starting a new session.

For full technical details on how the safety nets work, see docs/live/deployment-safety-nets.md in the repo.

Running deploy scripts manually

If CC can't run the scripts (e.g. you're not in a CC session), run them yourself from PowerShell in the mcc-systems repo root:

Migrations:

./scripts/deploy-prod.ps1

Edge Functions (specify function names):

./scripts/deploy-edge-prod.ps1 portal-contract portal-scope-of-work

Troubleshooting

Problem Fix
"Failed to parse connection string" Re-link: supabase link --project-ref jjroiufvngjhbvjfcrbv, enter your DB password, then retry
"Forbidden resource" Re-authenticate: supabase login, then retry
"Remote migration versions not found in local migrations directory" Your local repo is out of sync. Run git pull first, then retry
A migration fails during push The CLI will show the error. Migrations that haven't been applied won't be. Fix the migration file, commit, push, and retry
WARNING: Failed to switch back to dev You're still linked to prod. Run manually: supabase link --project-ref euhornpsmtwosgcpxuda