Multi-Stage Progressive Delivery Pipeline Specification
Architect an automated zero-downtime canary deployment pipeline with dynamic traffic shifting and automated rollbacks.
Use this template when transitioning mission-critical microservices from cutover deployments to resilient progressive delivery pipelines. It establishes metric evaluation gates, dynamic routing rules, and automated abort protocols.
Role: Principal Release Engineer with 12+ years of experience in distributed systems delivery and deployment automation.
Context
- Target Microservice: {{service_name}}
- Runtime Platform: {{target_orchestrator}}
- Ingress & Traffic Management: {{traffic_routing_mechanism}}
- Current Production Failure Baseline: {{current_failure_rate}}
- Target Maintenance Window SLA: {{deployment_sla_window}}
- Automated Abort Triggers: {{rollback_triggers}}
Task
Author a production-grade progressive delivery pipeline specification that transitions deployments from traditional cutovers to automated, traffic-weighted canary rollouts with zero customer-facing downtime.
Method
- Define baseline pipeline triggers, artifact signing validation, and pre-deployment health checks.
- Formulate the canary step ladder defining progressive traffic increments across specific time intervals.
- Specify metric collection queries for error rates, latency p99, and synthetic transaction health.
- Establish precise threshold boundaries connecting metric anomalies directly to {{rollback_triggers}}.
- Map traffic routing controls across {{traffic_routing_mechanism}} to isolate canary pods from baseline traffic.
- Design automated database migration sequencing and backward-compatible schema validation.
- Detail post-promotion cleanup routines, telemetry emission, and notification broadcasts.
Constraints
- MUST specify exact telemetry query formulas and evaluation windows for every promotion step.
- MUST NOT permit manual approval gates within automated canary validation loops.
- Architecture MUST comply with {{target_orchestrator}} native primitives without custom binary dependencies.
- All state transitions must maintain idempotent execution across abrupt runner cancellations.
- Rollback latency must complete within the constraints defined by {{deployment_sla_window}}.
Output format
- Architecture Overview (1-2 paragraphs defining the delivery topology)
- Canary Phase Schedule (structured table with Step, Traffic %, Hold Duration, Metric Gates)
- Rollback & Fail-Safe Specification (bulleted failure matrix and automated trigger definitions)
- Verification & Metrics Telemetry Definitions (named queries, evaluation windows, and alerting thresholds)
Self-review
- Ensure all variables are correctly integrated and operationalized.
- Verify canary progression intervals adhere to {{deployment_sla_window}}.
- Check that rollback procedures do not require manual intervention.
- Validate formatting against strict heading hierarchy.
Explicit role, a named task, and discrete steps the model can follow.
Background, inputs and variables the model needs before it starts.
Hard boundaries — what the model must and must not do.
A named, field-level shape for the response.
Ordered work items that force analysis before an answer.
Length and structure that travel across frontier models.
Signal density — instruction weight without padding.
Documented variables so the scaffold adapts to new inputs.
Quality bar, assumptions and behaviour when inputs are thin.
How much real usage the template has behind it.