Workflow: a safe Workers CI/CD pipeline

# Workflow: Workers CI/CD pipeline

## 1. Environments

Define `[env.staging]` and `[env.production]` in the Wrangler file, each with its own bindings (separate D1 databases, KV namespaces, R2 buckets, queues). Never share a production database binding with staging.

## 2. Secrets per environment

Set secrets with `wrangler secret put --env staging` / `--env production`. Declare required secret names in the config's `secrets` property so a deploy fails loudly when a secret is missing instead of the Worker failing at runtime. Remember: `wrangler secret put` deploys immediately; treat secret rotation as a deploy and verify it.

## 3. Preview URLs for PRs

Deploy PR branches to preview URLs (workers.dev or version URLs) and run integration tests against them: bindings wired, routes responding, scheduled handlers registered.

## 4. Staged rollout

Deploy to staging, run smoke tests (health endpoint, a write-and-read through each binding, a cron trigger dry run), then deploy to production. Keep the previous production version restorable: Wrangler keeps version history, and a rollback is a redeploy of the known-good version.

## 5. Post-deploy verification

Tail production logs during the deploy. Check error classes: a fresh 1101 is a code bug, a fresh 1102 is a CPU-limit problem. Verify `CF-Cache-Status` behavior if the Worker sits behind cache rules.

## Checklist

- Separate bindings per environment, no exceptions for databases.
- Required secrets declared; rotation treated as a deploy.
- Smoke tests hit every binding, not just the HTTP surface.