Deploy and promote

Answer

Code goes to staging with ./deploy.sh the moment it is tested, and to production only with tools/promote.sh, which ships staging's exact image after a backup and a clean gate and puts production back by itself if anything fails; this page is the operator's checklist for both.

Today

Sources: brew/deploy.sh:7-16 brew/deploy.sh:39-53 brew/tools/promote.sh:16-22 brew/tools/promote.sh:54-119 brew/tools/deploy-demo.sh:9-26

Rules in force

• Deploy after every tested change without asking; Param tests on the live staging URL. Still ask before anything that spends money or touches real ads or stores. memory always-deploy-to-test
• A deploy never waits for background work. The old instance stops starting Plays and saves; the new one resumes. Never add a wait back. brew/CLAUDE.md memory brew-pro-switch-and-flush
• Nothing dummy or from our testing reaches production; the clean gate refuses a promote on any finding. memory prod-clean-only brew/db/prod-clean.mjs:1-6
• One promote at a time, through the lock gs://brew-prod-backups/locks/promote.lock; a lock older than 2 hours is taken over. brew/tools/promote.sh:25-36
• Never edit promote.sh while it runs; bash reads it as it goes and that once caused a rollback. brew/.wt-prod/docs/production.md:33 memory brew-prod-backend
• After a staging deploy that ran on the bucket, run the brew-import job. brew/deploy.sh:30-32 memory brew-storage
• Model choice is set by environment at deploy time: staging defaults to Gemini, Pro for Plays and Flash for the rest. brew/deploy.sh:23-29 brew/deploy.sh:41

Tomorrow

How we do it

Staging

1. Commit only your lines, push, then deploy from a clean worktree of origin/main. memory brew-parallel-sessions-deploy

cd /Users/param/Documents/ChatGPT/brew
git pull --rebase && git push origin HEAD:main
git worktree add --detach "$TMPDIR/brew-deploy" origin/main
ln -s /Users/param/Documents/ChatGPT/brew/node_modules "$TMPDIR/brew-deploy/node_modules"
cd "$TMPDIR/brew-deploy" && BRANDS_DIR=/Users/param/Documents/ChatGPT/brew/.brands ./deploy.sh

2. Confirm the live site serves your commit: grep the served app.js for a new identifier and check the revision's git-sha label descends from your commit. memory brew-qa-sweep-2026-10-19
3. After a change on the pack or card path, time the seed, not just the status code:

curl -s -o /dev/null -w '%{time_total}\n' https://brew.joinsquareup.com/b/cozysnugglet-shop/seed.js

4. Roll back by hand if needed:

gcloud run services update-traffic shopos-feed --to-revisions=<rev>=100 --region=asia-south1

Production

1. Staging must run the commit you want, built from origin/main, and have been tested there.
2. From a clean checkout of origin/main:

tools/promote.sh

3. Read the eight steps as they print. Any STOP: line means production traffic did not move or was put back. ROLLBACK FAILED means put the named revision back by hand with update-traffic. brew/tools/promote.sh:49-52
4. If the lock is held and no promote is running: gcloud storage rm gs://brew-prod-backups/locks/promote.lock. brew/tools/promote.sh:32
5. After the promote, open feed.joinsquareup.com and one partner brand signed in.

Full step detail lives in Release and promote.

Numbers

Open

1. How often should production be promoted? No rhythm is written down; Next carries one pending promote of the 26 Oct jam fixes. Proposal: promote at most once a day, after Param has walked Arata and one other partner on staging.
2. Should staging smoke checks fail the deploy? Today they only print codes. Proposal: yes, fail on any non-200 from / or /api/config.