This repo collects some patterns (AKA strategies, models, approaches, best practices, etc.) about GitOps process design (AKA GitOps repository structures, etc.) as well as links to talks, articles and example repos.
It originated in schnatterer's talk about the "perfect" GitOps process, our experience in consulting, and our GitOps trainings for both Flux and ArgoCD.
You can read more about the patterns in this series of articles.
For questions or suggestions, you are welcome to join us at our community forum.
PRs welcome!
- Articles
- Pattern categories
- GitOps Patterns
- Operator deployment
- Repository structure
- Monorepo
- Repo per Team
- Repo per Application (can be implemented via Config-Code-Separation, Config Replication or Repo Pointer)
- Repo per Environment
- Promotion
- Wiring
- Bootstrapping
- Linking, includes Nesting (e.g. App of Apps), Templating
- Public GitOps Repo Examples
- Synonyms
- References
 |
Part 1️⃣: GitOps Chasm + categories |
 |
Part 2️⃣: Deployment patterns |
 |
Part 3️⃣: Repo patterns |
 |
Part 4️⃣: Promotion patterns |
 |
Part 5️⃣: Wiring patterns + conclusion |
Let's group GitOps patterns into separate categories to make them easier to grasp.
- Operator deployment: GitOps operators ↔ Clusters/Namespaces
- Repository: How many repos?
- Promotion:
- Environments: How to model environments/stages?
- Implementation: How to implement the actual process of promotion?
- Wiring: Bootstrapping operator, linking repos and folders
- Hub and Spoke 12 1 Operator : n Clusters
Synonyms: Management Cluster 3 - sounds familiar, e.g. from Cluster API, but it requires a cluster. In SaaS/PaaS constellations, the central instance may not even be operated in a cluster. Therefore, the term "Hub and Spoke" seems more fitting to us, especially since it is also well known from computer networks or logistics.
- Instance Per Cluster 3 : 1 Operator : 1 Cluster
Synonyms: Standalone 1 - could apply to both "Instance per Cluster" and "Instance per Namespace"; does not define the relationship to clusters and namespaces precisely enough, as not every operator supports both deployment patterns.
- Instance per Namespace: n Operators : 1 Cluster
Synonyms: Namespaced 4
More Patterns:
- Split-Instance1: 1 Operator : n Clusters; components split between management and target clusters
- Hybrids of Hub and Spoke and Instance per Cluster patterns: "Instance per Logical Group" and "Argo Managing more Argos".3
- Monorepo 25
Opposite: polyrepo 2 - Repo per Team 5
More generalized: Team ➡️ Tenant5 - Repo per Application 25
Implementations: - Repo per environment 5
Synonym: Environment per repository8, Repo per Stage
We understand the term "promotion" as the process of deploying applications to different environments.
Sometimes, the term "promotion" is prefixed with other words: Release/Application/Environment/Workload/Change.
For promotion, we see different sets of patterns:
- one regarding the modelling of environments and
- one regarding the implementation of the actual process of promotion.
- Folder/Directory per environment
Synonym: Environment per folder 8 - Repo per environment 5
Synonym: Environment per repo 8 - Branch per environment
Synonym: Environment per branch 8
Often discouraged 7 or declared an anti-pattern910, but can work 11. - Preview environments 12 13 14
Synonyms: ephemeral, dynamic, pull request15, test, temporary12
Beyond the GitOps world also known as "Preview Deployments"16 and "Deploy Previews"17
- Configuration Management
Synonyms: Templating, Patching, Overlay, Rendering- Plain kustomize (
kustomization.yaml) - "operator-agnostic" (works for Argo CD and Flux) - Helm
- via CRD such as
HelmRelease(Flux) orApplication(ArgoCD) - via Umbrella Chart18
- via
helm templateon CI server
- via CRD such as
- Plain kustomize (
- Global Environments vs Environment per App4
- Config update
Who updates image (version) in GitOps repo, creates branch and PR?- Manual: Human pushes branch and create PR 🥵
- CI Server: Build job pushes branch, creates PR
- Image Updater: Operator pushes branch, create PR manually
- Dependency Bot: Bot pushes branch, creates PR
- Bootstrapping ,
e.g. using
kubectlor operator-specific CLI such asfluxorargocd-autopilot - Linking
e.g. using Operator-specific CRDs such as
Kustomization(Flux) orApplication(ArgoCD)- Nesting, e.g. App of Apps pattern 19 (ArgoCD)
- Templating, e.g. implemented using
ApplicationSets
See also 4.
- Repo pattern: Per team mixed with per app
- Operator pattern: Instance per Cluster (Hub and Spoke also possible)
- Operator: ArgoCD (Flux)
- Boostrapping:
Helm,kubectl - Linking: ArgoCD
Application - Features:
- Env per app Pattern
- Operate ArgoCD with GitOps
- Config Update via CI server
- Mixed repo patterns
- ArgoCD and Flux examples
argoproj-labs/argocd-autopilot
- Repo pattern: Monorepo
- Operator pattern: Instance per Cluster / Hub and Spoke
- Operator: ArgoCD
- Boostrapping:
argocd-autopilot - Linking:
kustomization.yaml, ArgoCDApplication,ApplicationSet - Features:
- Operate ArgoCD with GitOps
- In the future: a lot more automation and YAML creation
fluxcd/flux2-kustomize-helm-example
- Repo pattern: Monorepo
- Operator pattern: Instance per Cluster
- Operator: Flux
- Boostrapping:
fluxCLI - Linking:
kustomization.yaml, FluxKustomization - Features: cross-cutting infra
- Repo pattern: Repo per team/tenant
- Operator pattern: Instance per Cluster
- Operator: Flux
- Boostrapping:
fluxCLI - Linking:
kustomization.yaml, FluxKustomization - Features: cross-cutting infra
christianh814/example-kubernetes-go-repo
christianh814/example-kubernetes-goflux-repo
christianh814/example-openshift-go-repo
- Repo pattern: Monorepo
- Operator pattern: Instance per Cluster
- Operator: [ArgoCD] [flux]
- Boostrapping: kubectl
- Linking:
kustomization.yaml,- ArgoCD
Application,ApplicationSet/ - Flux
Kustomization
- ArgoCD
- Features:
- Cross-cutting infra and app(s)
- ArgoCD and Flux examples
kostis-codefresh/gitops-environment-promotion
- Operator: ArgoCD (Flux)
- Features:
- Env variants for a single app
- Promotion "via cp"
- Patterns ≈ strategies, models, approaches, best practices, standards
- GitOps process design ≈ GitOps repository structures,
- GitOps Operator ≈ GitOps controller ≈ GitOps agent
- Config Repo = GitOps repo, Infra repo, Payload repo
- App repo = Source code repo, Source repo
- Environment = Stage
- Folder = Directory
- Templating ≈ Patching, Overlay, Rendering, Bundling, Packaging?
Footnotes
-
Article A Comprehensive Overview of Argo CD Architectures – 2023 by Dan Garfield ↩ ↩2 ↩3
-
Article/Book How to set up your GitOps directory structure by Christian Hernandez ↩ ↩2 ↩3 ↩4
-
Talk Control Plane, Service, or Both? – Argo CD Multi-Cluster Architectures - Nicholas Morey, Akuity, Article How many do you need? - Argo CD Architectures Explained by Nicholas Morey ↩ ↩2 ↩3
-
Slides The perfect GitOps process: repos, folders, stages, patterns by Johannes Schnatterer ↩ ↩2 ↩3 ↩4 ↩5
-
Documentation Flux | Ways of structuring your repositories ↩ ↩2 ↩3 ↩4 ↩5 ↩6
-
Documentation Argo CD: Best Practices ↩
-
Talk GitOps: Core Concepts & Ways of Structuring Your Repos by Pinky Ravi and Scott Rigby ↩ ↩2
-
Lesson GitOps at Scale Lesson series - Git repository strategies by Codefresh (paywalled) ↩ ↩2 ↩3 ↩4
-
Article Stop Using Branches for Deploying to Different GitOps Environments by Kostis Kapelonis ↩
-
Article Git best practices: Workflows for GitOps deployments by Christian Hernandez ↩
-
Article Monitoring and Hardening the GitOps Delivery Pipeline with Flux by Florian Heubeck ↩
-
Article Creating Temporary Preview Environments Based On Pull Requests With Argo CD And Codefresh by Codefresh ↩ ↩2
-
Talk GitOps Con Europe - Implementing Preview Environments with GitOps in Kubernetes by François Le Pape, Remazing ↩
-
Talk Preview Environments with ArgoCD by Brandon Phillips ↩
-
Video Environments Based On Pull Requests (PRs): Using Argo CD To Apply GitOps Principles On Previews by Viktor Farcic ↩
-
Documentation Vercel: Preview Deployments ↩
-
Documentation Netlify: Deploy Previews ↩
-
Documentation Helm | Chart Development Tips and Tricks ↩
-
Documentation ArgoCD: Cluster Bootstrapping - App Of Apps Pattern ↩