Deploy cadence + process proposal: 3 options for team review (Apr 2026)

deploy-cadence-proposal.md

Deploy Cadence + Process — Proposal for Team Review

UPDATE 2026-04-13 PM — Cadence finalized: Tue + Thu pushes.

After team feedback (Ahmed +1'd alternate-day on this gist; Gaurav locked in the specific days), the cadence is:

Day	What happens
Mon	Build deployment/ branch → forward-integrate master → QA in PM → Megan signs off by 5pm
Tue AM	Push Mon's approved package → prod
Tue PM	Team works on PRs for Wed's build (Megan: light QA load, use for ops/KPI)
Wed	Same as Mon — build → QA → sign-off for Thu push
Thu AM	Push Wed's approved package → prod
Thu PM	Team works on PRs for next Mon's build
Fri	Spillover / no fixed deploy. Buffer for Thu-push fallout, backlog catch-up, weekly recap. If truly critical → hotfix lane.

Two pushes per week (Tue + Thu). Fri stays deploy-free so the team heads into the weekend with prod in a known-good state.

The 5 non-negotiables below still ship regardless of cadence — next step is building them this week alongside fraud + Pro Plan launch.

Still want feedback from Megan + Mahmoud on the non-cadence questions (tracking dashboard, pain points, visual QA flow) — those are still open.

---

Original context

Context: We're moving from weekly-ish pushes to more frequent deploys. Gaurav initially asked for daily pushes; I drafted an hour-by-hour plan; he pushed back that it felt over-structured. This gist had 3 simpler options for the team to react to.

What was not on the table: Keeping the current weekly rhythm. We're pushing more often. The question was how often and with what process around it.

---

What's broken today (still true — the cadence change doesn't solve these)

1. No source of truth for "what's in today's deploy package." Megan infers it from GitHub PR labels + Ahmed's Slack messages + the digest. She tracks ticket-level QA status in her head.
2. No per-ticket QA record. When a blocker is found, it's announced in Slack but not captured anywhere persistent. It doesn't gate the push programmatically.
3. Forward-integration wasn't happening until the April 8 regression incident (deployment/2026-04-08 silently reverted 2 files). Now encoded in process but not enforced by tooling.
4. Release notes are ad-hoc. Sometimes Ahmed writes them, sometimes no one does.
5. No clear "push or slip" decision point. Packages sometimes sit on staging for days waiting for someone to decide they're ready.

---

Three cadence options (for historical reference — the Tue/Thu finalization above supersedes these)

Option A — Daily pushes

Build every day, push every day. Small batches (2-4 PRs), ~17h from staging merge to prod.

Verdict: Rejected. Ahmed's feedback: "alternate-day is so much more realistic than daily pushes." Daily was too much context-switching for a 4-person team with Megan as QA bottleneck.

Option B — Alternate-day pushes (my original recommendation — morphed into final)

Two pushes per week: Wed AM + Fri AM in my original draft. Gaurav's tweak: Tue + Thu instead, with Fri as spillover. Final version above.

Option C — Just better tracking, no cadence change

Build a dashboard + DB, keep cadence loose. Rejected because we do want the faster rhythm — just not daily.

---

The 5 non-negotiables (still ship regardless)

These are independent of cadence and still need to ship this week alongside fraud + Pro Plan launch:

1. deploy_packages source of truth — DB table + simple dashboard. Megan QAs ticket-by-ticket on the dashboard instead of holding it in her head.
2. Risk label requirement — every PR gets risk:L, risk:M, or risk:H at creation (hook-enforced). Drives Megan's tiered QA.
3. Forward-integration enforced in tooling — guard-master-commit.sh already blocks git commit on master; extend it to block local git merge too, forcing deployment→master through a GitHub PR (so merge-regression-check CI fires every time).
4. Automated release notes — webhook on deployment→master PR merge generates notes from commit log, posts to #dev-feed + writes docs/release-notes/YYYY-MM-DD.md. No manual step.
5. Hotfix lane — documented process for P1 revenue/security items that bypass the cadence entirely. Single-PR fast-track with merge-regression-check still firing. Already used today (PostHog #3959).

---

Still-open questions for Megan + Mahmoud (non-cadence)

Megan:

• You drafted a daily AM-push/PM-QA rhythm — does the Tue/Thu version work better for your capacity?
• What's the most time-consuming part of your QA work today?
• Would a dashboard where you click pass/blocker per ticket actually save you time, or is it just more clicks?

Mahmoud:

• Where does visual QA get rushed or dropped today?
• Would a dashboard showing "your visual QA items for today's package" help?
• Are you OK doing 5-10 min of visual QA on prod on Tue + Thu mornings (right after Ahmed pushes)?

Everyone — open question: What process thing is hard for you right now that isn't about cadence? (Examples: PR review queue unclear, no risk labels, hard to find what's on staging, smoke tests flaky, no release notes, tickets re-opened after "fix", too many pings, context-switching between fraud/Pro/pipeline, something else.)

---

Next steps

• Cadence locked: Tue + Thu pushes, Mon + Wed build, Fri spillover
• Memory + daily-digest skill updated to encode the new rhythm (commit on PR #3989)
• Build the 5 non-negotiables this week (deploy_packages dashboard, risk labels, forward-integration enforcement, release notes automation, hotfix lane doc)
• Get Megan + Mahmoud feedback on the dashboard UX before building (async — whenever they have time this week)
• Update workflow.md and CLAUDE.md with the new cadence rules (after Megan + Mahmoud confirm there are no open objections on the Tue/Thu specifics)

— Gaurav + Claude (drafted 2026-04-13, updated same day with Tue/Thu finalization)

alternate-day is so much realistic than daily pushes

1. Agree - alternate date push is a better plan here. Love the Tuesday/Thursday planning, with day between to prep
2. For me hardest part of QA is: sanity checking our current flows, reviewing smoke test, and then testing against tickets for the push. It's just time consuming.
3. yes - would love a dashboard to ensure I'm checking off on everything in the branch. Or flag issues on a ticket.

1- Where does visual QA get rushed or dropped today?
Honestly we don't test on staging that much any more, our testing is more condensed on the QA server itself before deploying.

2- Would a dashboard showing "your visual QA items for today's package" help?
Yes

3- Are you OK doing 5-10 min of visual QA on prod on Tue + Thu mornings (right after Ahmed pushes)?
Yes