One Application is easy. Real organizations run dozens across dev, staging, and prod. This lesson covers the App of Apps pattern, how to structure your Git repos, and the practices that keep GitOps sane at scale.

🎯 Learning Objectives

• Understand the App of Apps pattern
• Structure repositories for multiple environments
• Separate config from code with overlays
• Apply production GitOps best practices

The App of Apps Pattern

Instead of creating each Application by hand, you create one parent Application that itself points at a folder of child Application manifests. Argo CD then manages the children automatically.

root-app (Application)
└─ points at git path "apps/"
     ├─ app-frontend.yaml   (Application)
     ├─ app-backend.yaml    (Application)
     ├─ app-monitoring.yaml (Application)
     └─ app-argocd.yaml     (Application)  ← even Argo CD config itself

Now onboarding a new service is a single commit — add its Application YAML to apps/ and the root app syncs it into existence. This is how teams manage fleets of apps from one Git repo.

Structuring Your Repos

A common, clean layout separates what the app is from how each environment configures it, using Kustomize overlays:

my-app/
├── base/                 # shared manifests
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/
  ├── dev/
  │   └── kustomization.yaml   # e.g. 1 replica, debug on
  ├── staging/
  │   └── kustomization.yaml
  └── prod/
      └── kustomization.yaml   # e.g. 5 replicas, resource limits

Each environment gets its own Argo CD Application pointing at the matching overlay path. The base stays DRY; overlays hold only the differences.

Production Best Practices

• Everything in Git — no manual kubectl apply in production. If it’s not in Git, it doesn’t exist.
• Enable selfHeal and prune in production so drift can’t accumulate.
• Protect branches — require pull-request review for the config repo; that review is your deployment approval.
• Promote by PR — moving from staging to prod is a pull request bumping a version, giving you a full audit trail.
• Use Projects (AppProjects) to restrict which repos, clusters, and namespaces a set of apps may touch — essential for multi-team clusters.
• Sync notifications — wire Argo CD notifications to Slack so the team sees deploys and failures.

Rollback the GitOps Way

Because Git is the source of truth, rollback is just Git:

# revert the bad change — Argo CD re-syncs to the previous state
git revert <bad-commit>
git push

# or roll an app back to a previous revision directly
argocd app rollback my-app <history-id>

No special tooling, no snowflake procedure — the same workflow you already use for code.

🧪 Hands-on Lab

🧠 Knowledge Check

💼 Interview Preparation

Summary

You’ve completed the Argo CD track: GitOps principles, installation, sync and self-healing, and scaling with App of Apps and solid production practices. You can now deploy and manage whole fleets of apps declaratively from Git. Next, we shift from deployment to debugging distributed systems with tracing in Zipkin.