Deploy, migrate, and roll back

Code rollback is straightforward only when the database and message formats remain compatible with both versions.

Use additive D1 migrations before code that depends on them, deploy with a clear version message, run smoke checks, and keep the previous version available. Make queue consumers tolerate messages created by the previous producer during rollout.

Record the published version ID and the exact checks that passed. A useful sequence is expand the schema, deploy tolerant code, observe it, and remove old fields only in a later release after the rollback window. Version Queue messages so an older consumer can reject or safely ignore a format it cannot process.

wrangler rollback changes the active Worker deployment, but it does not roll back D1 data, KV values, R2 objects, Queue effects, or external APIs. It may also be unavailable when required bindings or Durable Object classes no longer match the old version. Test the rollback while those dependencies still exist, then smoke-test the restored version and reconcile Git so the next deployment does not reintroduce the failure.

Write a release sequence for adding an optional link description, including migration, code, smoke test, and rollback.