GitOps & ArgoCD

How Blueberry IDP leverages ArgoCD’s App-of-Apps pattern to declaratively manage every environment.

Why GitOps?

GitOps treats Git as the single source of truth for both application code and infrastructure. ArgoCD continuously reconciles the desired state (in Git) with the actual state running in the cluster, giving us auditability, instant rollbacks and a zero-touch deployment pipeline.

Every change is peer-reviewed via merge request
Cluster drift is detected & auto-healed
Rollbacks are as easy as reverting a commit
No humans with kubectl in production clusters

App-of-Apps Pattern

A single root Application manages one child Application per environment. Each child in turn owns backend, database and one-or-more frontends.

graph TD Root[ArgoCD Root Application] --> Env1[Environment: pr-123] Root --> Env2[Environment: feature-x] Env1 --> Backend1[Backend Chart] Env1 --> FE1A[Frontend A] Env1 --> FE1B[Frontend B] Env2 --> Backend2[Backend Chart] Env2 --> FE2A[Frontend A]

ArgoCD root app instantiates one child per environment

Sync Waves

Resources are applied in waves so dependencies are honoured but parallelism is maximised:

Wave 0: Namespace, Redis, ConfigMaps
Wave 1: Backend Deployment & Service
Wave 2: Frontend Deployments & Services
Wave 3: Ingresses (expose services once backends are ready)

Operational Tips

✅ Do

Commit Helm value overrides alongside application code
Use selfHeal: true so ArgoCD fixes drift automatically
Define syncOptions: CreateNamespace=true for child apps
Tag root & child apps with blueberry.io/* labels for easy cross-filtering

❌ Don’t

Use kubectl apply directly – it breaks GitOps flow
Disable pruning; stale resources cause unpredictable behaviour
Store secrets in Git, even if the repo is private
Use latest tags – always pin image digests for reproducibility

Questions? Jump into the #blueberry channel or open an issue on GitLab.