What this prompt does
This prompt makes the AI a deployment engineering specialist that designs a zero-downtime deployment strategy for your application. You provide the [tech_stack], the [infrastructure], your [current_deployment], the [database_info], and the [traffic_volume], and it works through six phases: strategy selection, a database migration plan, implementation config, a rollback procedure, a verification checklist, and a 3 AM runbook. It compares blue-green, canary, and rolling strategies for your specific case rather than recommending one in the abstract.
The structure works because it focuses on where zero-downtime deploys actually fail: the database. Phase 2 designs backward-compatible schema changes and the expand-contract pattern (expand, migrate, contract) so old and new code coexist during rollout, plus an online-DDL approach for large tables and a rollback plan. Phase 3 generates the [infrastructure] config including health checks and separate readiness versus liveness probes, with extras from [additional_config]. Phase 5 adds your [verification_step], and the runbook is written so an on-call engineer can follow it half-asleep.
When to use it
- Your current deploys take the app down during migrations and you want that gone
- You need a reasoned choice between blue-green, canary, and rolling for your setup
- You have a large table and need an expand-contract migration that won't strand data
- You need health-check, readiness, and liveness probe configs for your platform
- You want automatic rollback triggers and a manual rollback command sequence
- You need a copy-paste runbook an on-call engineer can run at 3 AM
Example output
You get a filled-in strategy comparison table with a recommendation and reasoning, an expand-contract migration plan for your schema changes, [infrastructure] deployment manifests with health checks and readiness/liveness probes, a rollback procedure with automatic triggers and manual commands, a post-deploy verification checklist, and a step-by-step 3 AM runbook with copy-paste-ready commands.
Pro tips
- Describe
[current_deployment]honestly, including the downtime it causes, so the comparison addresses your real pain - Give accurate
[database_info](engine, size, largest table row count) since migration strategy hinges on it - Set
[traffic_volume]realistically, especially if you have no quiet deployment window - Match
[infrastructure]exactly so the generated manifests and probes are usable, not illustrative - Use
[verification_step]for the thing you most fear breaking, like Stripe webhook processing post-deploy - Validate the migration's reversibility yourself; an AI-claimed reversible migration still needs testing against a copy of prod
