Create a Production Deployment Checklist Covering Rules, Indexes, Billing, Backups, Observability, and Rollback

1. AtlasMart go-live: a checklist must be executable evidence

A release checklist that says “security tested,” “indexes okay,” and “backups enabled” is not operational control. Each item needs an owner, command/evidence, environment, pass condition, rollback action, and timestamp. Chapter 26 ends by converting the previous 25 chapters into a release gate that distinguishes local proof from managed production proof.

2. Release evidence record

{  "release": "atlasmart-2026-09-17.1",  "commit": "<git-sha>",  "firebaseCli": "15.30.0",  "runtime": "node-22",  "database": { "edition":"standard", "mode":"native", "id":"(default)", "location":"<verify-managed>" },  "local": {    "project":"demo-atlasmart-firestore",    "rulesTests":"PASS",    "integrationTests":"PASS",    "migrationAudit":{"mismatches":0,"unreadable":0}  },  "managed": {    "stagingIndexCanary":"PENDING",    "iamCanary":"PENDING",    "billingBudgetAlerts":"VERIFY",    "backupPitrDrill":"VERIFY",    "observabilityDashboards":"VERIFY"  },  "rollback": { "featureFlag":"documented", "previousRulesSha":"<sha>", "owner":"release-oncall" }}

3. Gate 1 — repository and environment identity

4. Gate 2 — Rules and trust boundaries

5. Gate 3 — indexes and query contracts

6. Gate 4 — schema/migration/backfill

7. Gate 5 — billing, quota, abuse and capacity

8. Gate 6 — backup, PITR, retention and recovery

9. Gate 7 — observability and incident response

10. Deployment order: expand before contract

11. Canary thresholds must exist before traffic

{  "windowMinutes": 30,  "rollbackIf": {    "permissionDeniedRate": "> baseline + agreed delta",    "dualReadMismatchRate": "> 0 for price fields",    "unreadableDocumentCount": "> 0",    "p95Latency": "> release SLO budget",    "errorRate": "> release SLO budget",    "unexpectedCostMultiplier": "> 1.25x modeled canary envelope"  },  "note": "Thresholds are product/SLO decisions; these labels are not universal Firestore values."}

12. Controlled failure drill: rollback under a mixed-version dataset

Inject a canary failure after 40% of documents are migrated to v2. The correct rollback is:

1. Stop rollout / disable v2-preferred feature flag.
2. Pause backfill.
3. Confirm v1/dual reader serves both migrated and unmigrated documents.
4. Restore prior Rules only if compatible with the mixed dataset; otherwise keep the expanded Rules while application is rolled back.
5. Preserve v2 fields; do not run destructive reverse migration during the incident.
6. Record decision, timestamps, mismatch/error counts and recovery of SLO.

13. Edition/mode matrix for the final gate

14. Mandatory local deployment rehearsal

1. Run the full demo-project CI from clean seed.
2. Hash Rules/index files and write release evidence JSON.
3. Run schema-v2 failure injection, resume and audit.
4. Simulate index readiness state and refuse to enable the feature until it reads READY.
5. Enable a deterministic 25% canary cohort; inject a mismatch and assert rollback policy disables it.
6. Produce final checklist with every cloud-only item marked VERIFY_MANAGED—never fake PASS.

Production judgment and bridge to Chapter 27

The checklist is not bureaucracy; it is the boundary between a collection of Firestore features and an operable system. Chapter 27 uses this release discipline in the capstone: design the model, security, scaling, retrieval, recovery and operations together, then defend the decisions with measured evidence.

Knowledge check

1. Why must a checklist item contain evidence and a rollback action?
2. What should happen before releasing code that needs a new composite index?
3. Why can Rules rollback be unsafe after a schema migration begins?
4. What is the correct response to a canary failure in a mixed-version dataset?
5. Why must cloud-only checklist items remain VERIFY_MANAGED locally?

Authoritative references

• Firebase: Connect your app to the Cloud Firestore Emulator — demo projects, edition selection, Admin SDK environment variables, reset/import/export, Rules reports, and production differences.
• Firebase: Install, configure and integrate Local Emulator Suite — emulators:exec, import/export and CI workflow.
• Firebase: Test Cloud Firestore Security Rules — emulator rules testing and CI execution.
• Firebase: Build Security Rules unit tests — @firebase/rules-unit-testing, mocked auth, clearing state and disabled-rules fixture setup.
• Firebase: Manage and deploy Security Rules — source control, local testing and selective deployment.
• Firebase: Manage indexes in Cloud Firestore — source-controlled index definitions and CLI deployment.
• Firebase: Cloud Firestore index definition reference — composite, field override and vector index JSON shapes.
• Firebase CLI reference — configured multi-database rules/indexes and deployment selectors.