What this prompt does
This prompt designs an end-to-end zero-downtime deploy pipeline tight enough to implement. It casts the assistant as a senior DevOps engineer and feeds four context variables — [app_type], [platform], [database], and [rps] (requests per second). The deliverables cover CI stages with dependency and build caching, artifact promotion across dev, staging, and production using the same immutable build, a blue/green versus canary tradeoff for the given traffic with a recommendation, a safe schema-migration strategy that never blocks a deploy, automatic rollback triggers tied to error rate, latency, and saturation, and observability at each stage. The output is a Mermaid diagram plus a concise release runbook.
The structure works because it ties every decision to your actual numbers and platform rather than producing generic advice. The [rps] variable shapes the blue/green-versus-canary recommendation directly, since traffic level changes which strategy is safer. Forcing a separate safe-migration section addresses the most common cause of dangerous rollbacks — schema changes coupled to code deploys. The rollback-triggers requirement makes the pipeline self-protecting instead of relying on a human noticing the dashboards in time.
When to use it
- When a service has outgrown deploying by hand and needs a real pipeline
- When you need true zero-downtime releases under meaningful traffic
- When schema migrations keep making rollbacks scary
- When you want automatic rollback rather than manual incident response
- When choosing between blue/green and canary for a specific traffic profile
- When you need a clear diagram and runbook to hand to a team
Example output
You get a Mermaid diagram of the full pipeline — CI stages, artifact promotion, the chosen release strategy, migration steps, and rollback paths — plus a concise runbook for a normal release. The blue/green-versus-canary section ends with a recommendation justified for your [rps], so the choice is tied to your traffic rather than a generic preference. The migration strategy is written to decouple schema changes from code deploys, and the rollback section names the exact error-rate, latency, and saturation thresholds that trigger an automatic revert. The runbook reads as an ordered sequence a release engineer can follow, while the diagram serves as the shared reference everyone reviews before the first real deploy.
Pro tips
- Give
[rps]a realistic peak figure, not an average, since the release-strategy recommendation hinges on it - Name
[platform]and[database]precisely ("AWS ECS Fargate", "RDS PostgreSQL Multi-AZ") so the steps are concrete and runnable - Insist that the migration strategy decouples schema changes from code; coupled migrations make every rollback dangerous
- Treat the rollback thresholds as a starting point and tune them against your real baselines
- Use the Mermaid diagram as the shared artifact in review, then refine the runbook after the first real release
- If the canary stage feels hand-wavy, ask for explicit traffic-percentage steps and bake times
