GitOps and Canary Deployment Rollout Roadmap
Plan a declarative GitOps adoption strategy using automated canary analysis and progressive delivery gates.
Apply this template when designing a transition to declarative, repository-driven Kubernetes deployments. It outlines progressive traffic shifting, metric-driven canary verification, and automated rollback orchestration.
Role: Staff Site Reliability Engineer specializing in GitOps implementations, traffic management, and progressive delivery.
Context
- Kubernetes cluster environment: {{k8s_cluster_topology}}
- Declarative GitOps engine: {{gitops_controller}}
- Service mesh or ingress traffic manager: {{traffic_router}}
- Observability and metrics stack: {{observability_stack}}
- Automated rollback thresholds and SLOs: {{rollback_slos}}
- Target application tiers for rollout: {{service_tier_scope}}
Task
Develop an implementation plan for establishing a declarative GitOps deployment workflow across {{k8s_cluster_topology}} using {{gitops_controller}}, incorporating automated canary analysis via {{traffic_router}} and {{observability_stack}} for {{service_tier_scope}} to strictly uphold {{rollback_slos}}.
Method
- Define Git repository hierarchy, branching model, and multi-environment reconciliation boundaries.
- Design the configuration sync engine using {{gitops_controller}} with drift detection and automated remediation.
- Configure canary releaseCRDs integrating {{traffic_router}} for percentage-based traffic routing.
- Construct analysis templates querying {{observability_stack}} for real-time error rate, latency, and throughput comparison.
- Formalize automated rollback rules triggered immediately when breaching {{rollback_slos}}.
- Create access control boundaries and automated PR validation mechanisms for infrastructure repositories.
- Map out a step-by-step rollout across {{service_tier_scope}}, from internal services to tier-1 user paths.
Constraints
- MUST eliminate direct cluster access (kubectl write permissions) in favor of Git-driven operations.
- MUST NOT configure canary step intervals without automated metric health evaluations between increments.
- Rollout steps must provide clear operational runbooks for emergency manual interventions.
- All repository structures must isolate tenant application manifests from core infrastructure code.
Output format
- GitOps Repository & Directory Architecture (ASCII directory tree + branch policy)
- Progressive Delivery Specification (traffic step percentages, pause durations, and metric queries)
- Rollback & Automated Abort Protocol (flowchart-style logic and trigger thresholds)
- Phased Rollout Schedule (4 stages with milestones, testing gates, and sign-off criteria)
- Operational Runbook for Incidents (step-by-step operator emergency procedures)
Self-review
- Validate that the traffic progression explicitly leverages {{traffic_router}} capabilities.
- Ensure the metric verification steps query {{observability_stack}} accurately against {{rollback_slos}}.
- Confirm the plan strictly covers the operational scope of {{service_tier_scope}} without unmanaged dependencies.
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.