DevOps & CI
AuraScore 81/100

GitOps Progressive Delivery Canary Deployment Specification

Design an automated canary rollout specification using GitOps synchronization and progressive delivery.

Use this template to specify automated traffic shifting, health verification, and rollback automation within Kubernetes clusters managed by GitOps controllers.

Template

Role: Lead Platform SRE Architect with deep expertise in GitOps synchronization engines, service meshes, and automated remediation.

Context

  • Target Kubernetes cluster tier and topology: {{kubernetes_cluster_tier}}
  • GitOps controller and synchronization engine: {{gitops_tooling}}
  • Service mesh or ingress traffic router: {{traffic_manager}}
  • Primary golden signal metrics and SLO thresholds: {{slo_metrics}}
  • Automated rollback thresholds and criteria: {{rollback_triggers}}
  • Canary traffic ramp-up schedule and evaluation intervals: {{canary_step_intervals}}

Task

Produce an exhaustive engineering specification for a GitOps-driven progressive delivery canary system that manages traffic shifting, real-time telemetry validation, and automated rollback orchestration.

Method

  1. Define the repository structure, branch synchronization, and CRD manifests for {{gitops_tooling}}.
  2. Configure traffic splitting mechanisms via {{traffic_manager}} to decouple release from deployment.
  3. Translate {{canary_step_intervals}} into step-by-step traffic weight percentage tiers and stabilization pauses.
  4. Specify statistical metric analysis queries against {{slo_metrics}} for each evaluation interval.
  5. Design automated fast-rollback mechanisms that execute immediately upon violating {{rollback_triggers}}.
  6. Establish GitOps reconciliation locks during active canary cycles to prevent state drift.
  7. Detail post-promotion cleanup, baseline synchronization, and incident webhook notification payloads.

Constraints

  • MUST define automatic, zero-human-intervention rollbacks if {{rollback_triggers}} are breached.
  • MUST NOT allow GitOps drift reconciliation to override an ongoing canary state machine.
  • Traffic shifts must strictly adhere to the intervals specified in {{canary_step_intervals}}.
  • Health evaluation metrics must be derived exclusively from {{slo_metrics}} baseline parameters.

Output format

Deliver the document using the following structured sections:

  1. Progressive Delivery System Architecture
  2. Traffic Routing & Canary Split Configuration
  3. Metric Analysis & Decision Engine Matrix
  4. Rollout Schedule & Step Progression Table
  5. Fast-Rollback State Machine & Alert Routing Total word count: 900–1,300 words.

Self-review

  • Validate that metric queries in section 3 map directly to {{slo_metrics}}.
  • Ensure rollback mechanisms are guaranteed to be fully automated without human confirmation.
  • Check that GitOps synchronization conflicts with active canary steps are explicitly mitigated.
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
gitops
canary-deployment
sre