Architecture
A GitOps deployment architecture diagram with developer Git workflow, CI/CD pipeline building and pushing container images, ArgoCD or Flux detecting Git manifest changes, drift detection, automatic cluster synchronization, and rolling update deployment to Kubernetes. This template models the GitOps paradigm where Git is the single source of truth for both application code and infrastructure state, enabling declarative, auditable, and reproducible deployments. Critical for teams adopting GitOps practices for Kubernetes deployments.
Full FlowZap Code
Developer { # Developer
n1: circle label:"Code Change"
n2: rectangle label:"Git Push to Main"
n3: rectangle label:"Open Pull Request"
n4: rectangle label:"Merge After Review"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="Feature Branch"]
n3.handle(right) -> n4.handle(left) [label="Approved"]
n4.handle(bottom) -> CICD.n5.handle(top) [label="Trigger"]
}
CICD { # CI/CD Pipeline
n5: rectangle label:"Run Tests and Lint"
n6: rectangle label:"Build Container Image"
n7: rectangle label:"Push to Registry"
n8: rectangle label:"Update Manifest in Git"
n5.handle(right) -> n6.handle(left) [label="Tests Pass"]
n6.handle(right) -> n7.handle(left) [label="Tag: sha-abc123"]
n7.handle(right) -> n8.handle(left) [label="Update Image Tag"]
n8.handle(bottom) -> GitOps.n9.handle(top) [label="Commit Manifest"]
}
GitOps { # GitOps Controller (ArgoCD/Flux)
n9: rectangle label:"Detect Git Diff"
n10: rectangle label:"Compare Desired vs Live"
n11: diamond label:"Drift Detected?"
n12: rectangle label:"Sync to Cluster"
n13: rectangle label:"State Already Synced"
n14: rectangle label:"Health Check"
n9.handle(right) -> n10.handle(left) [label="Poll/Webhook"]
n10.handle(right) -> n11.handle(left)
n11.handle(right) -> n12.handle(left) [label="Yes"]
n11.handle(bottom) -> n13.handle(top) [label="No"]
n12.handle(right) -> n14.handle(left) [label="Apply"]
n14.handle(bottom) -> Cluster.n15.handle(top) [label="Deploy"]
}
Cluster { # Kubernetes Cluster
n15: rectangle label:"Rolling Update Deployment"
n16: rectangle label:"New Pods Created"
n17: rectangle label:"Old Pods Terminated"
n18: rectangle label:"Service Routes Traffic"
n19: circle label:"Deployment Complete"
n15.handle(right) -> n16.handle(left) [label="Scale Up"]
n16.handle(right) -> n17.handle(left) [label="Healthy"]
n17.handle(right) -> n18.handle(left) [label="Cutover"]
n18.handle(right) -> n19.handle(left)
}
Why This Workflow?
Manual deployments and imperative scripts are error-prone, hard to audit, and impossible to reproduce. GitOps makes Git the single source of truth for infrastructure state, enabling declarative deployments where every change is version-controlled, peer-reviewed, and automatically applied to the cluster.
How It Works
- Step 1: A developer pushes code changes and opens a pull request.
- Step 2: The CI/CD pipeline runs tests, builds a container image, and pushes it to the registry.
- Step 3: The pipeline updates the Kubernetes manifest in Git with the new image tag.
- Step 4: ArgoCD or Flux detects the Git change and compares desired state with live cluster state.
- Step 5: If drift is detected, the controller automatically syncs the cluster to match Git.
- Step 6: Rolling updates deploy new pods, health checks verify them, and old pods are terminated.
Alternatives
Imperative CI/CD pipelines (Jenkins) push changes directly to clusters without drift detection. Helm charts provide templating but not continuous reconciliation. This template shows the full GitOps workflow with ArgoCD/Flux.
Key Facts
| Template Name | GitOps Deployment Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
Architecture
A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.
Architecture
A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.
Architecture
A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency.
Architecture
A microservices decomposition architecture diagram organized by business capabilities: Identity, Product Catalog, Pricing, and Order Fulfillment, each with independent data stores and APIs. This template shows how to break a monolith into services aligned with business domains, using a Backend-for-Frontend (BFF) pattern for client-specific aggregation. Useful for architects planning domain-driven microservice boundaries.
Architecture
A strangler fig migration architecture diagram showing the incremental replacement of a legacy monolith with new microservices, using a routing layer to split traffic between old and new systems. This template models the proven migration strategy where new features are built as microservices while legacy endpoints are gradually retired. Essential for teams modernizing legacy systems without risky big-bang rewrites.
Architecture
A service discovery architecture diagram with Consul or Eureka registry, client-side load balancing, health check heartbeats, and automatic instance registration and deregistration. This template visualizes how microservices dynamically locate each other without hardcoded endpoints, enabling elastic scaling and self-healing infrastructure. Key for platform teams building resilient service-to-service communication.