DevOps & CI
AuraScore 81/100

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.

Template

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

  1. Define baseline pipeline triggers, artifact signing validation, and pre-deployment health checks.
  2. Formulate the canary step ladder defining progressive traffic increments across specific time intervals.
  3. Specify metric collection queries for error rates, latency p99, and synthetic transaction health.
  4. Establish precise threshold boundaries connecting metric anomalies directly to {{rollback_triggers}}.
  5. Map traffic routing controls across {{traffic_routing_mechanism}} to isolate canary pods from baseline traffic.
  6. Design automated database migration sequencing and backward-compatible schema validation.
  7. 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

  1. Architecture Overview (1-2 paragraphs defining the delivery topology)
  2. Canary Phase Schedule (structured table with Step, Traffic %, Hold Duration, Metric Gates)
  3. Rollback & Fail-Safe Specification (bulleted failure matrix and automated trigger definitions)
  4. 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.
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-devops
technology-software
devops
ci-cd
canary-deployment