Deployment & Change Matrix

A “what do I do after I changed X?” map so you do not restart unrelated systems.

Change → action matrix

You changed…	What you must do next	What you do NOT need
Git source file	Commit/push; Git-integrated Pages builds automatically unless paused.	No manual DNS change.
Pages root/build/output	Redeploy and retest Functions/static routes.	No D1 schema change unless code requires it.
D1 binding	Redeploy affected Pages project.	No Access recreation.
R2 binding	Redeploy affected Pages project.	No DNS change.
Plain variable/secret	Deploy/redeploy affected runtime.	No team-domain rewrite.
Access policy email	Save policy; user may need new session.	No Command code deploy.
Access application recreated	Copy new AUD → update `CF_ACCESS_AUD` → redeploy Command.	No D1 reset.
Zero Trust team domain	Verify team-domain URL; update `CF_ACCESS_TEAM_DOMAIN`; verify/recreate dependent Access config; redeploy Command.	Do not delete D1/R2.
Command custom domain	Use Pages Custom domains flow; verify Active; then apply Access.	Do not manually point random A record.
OBS scene/input name	Update agent/Command mapping and rehearse.	No Pages redeploy unless mapping is in code/config there.
Broadcast Agent secret	Update both Command secret and agent env; redeploy/restart; test.	No Access human-policy change.

Safe deployment sequence for any code change

1. Make change locally
2. Run relevant local/static tests
3. Commit to branch
4. Deploy preview/staging
5. Test actual API + UI
6. Review diff
7. Merge/push production branch
8. Watch Pages deployment
9. Smoke-test production
10. Record rollback commit/deployment

When to create a new deployment manually

Create/retrigger a deployment after binding/variable/secret changes that must be visible to Pages Functions, after updating the production source commit, or after correcting build configuration. Do not redeploy merely because you changed D1 rows or uploaded R2 objects through the running application.

v24 migration and deployment order

Change	Required action
Deploy v24 over v23	Back up D1 → apply `MIGRATIONS/v24-rundown-traffic.sql` once → deploy Command → deploy HVN → run staging rundown/traffic acceptance.
Schedule-only edit	No deployment. Build/edit the selected market/day in Command, then explicitly Publish and/or Approve as appropriate.
Website EPG change	Publish or Unpublish the selected market/day. No playout arm is implied.
Commercial clock change	Update/replace the Break Builder clock, then verify every scheduled break block referencing it before air approval.
Program master replacement	Upload/QC the new master, attach it to the exact block/market, re-run Day Readiness, then re-approve if operational policy requires.