Sign in Get started

Helm, Kustomize and GitOps with Argo CD · Capstone

Capstone: A GitOps Platform for Three Environments and Many Teams

Design repositories, packaging, Argo CD structure, secrets and promotion for 25 services across dev, staging and production.

Create a free account to save this page, take notes and track your progress. Sign in

Scenario

Example company: 25 microservices owned by 6 teams, three clusters (dev, staging, prod) plus a second production region next quarter. Deployments today are helm upgrade commands run from laptops with values files that differ per person.

Requirements

  • Every change to a cluster is a reviewed commit; production changes need approval.
  • Teams can deploy their own services without platform help, but can't change other teams' services or cluster add-ons.
  • A new cluster gets all platform add-ons automatically.
  • No secret values in Git.

Constraints

  • Mixed packaging: 10 services have Helm charts, the rest plain YAML.
  • Database migrations accompany about one release in five.

Deliverables

  1. Repository layout and packaging conventions.
  2. Argo CD structure: projects, Applications, ApplicationSets, sync policies.
  3. Ordering and safety: migrations, drift, deletions.
  4. Secrets.
  5. Promotion from dev to production.

Hints

  • Separate what teams own from what the platform owns.
  • Argo CD projects restrict sources, destinations and resource kinds.

Draft each deliverable below before revealing the model answer and rubric.

Further reading: Argo CD best practices · Projects

Deliverables

Describe the repository layout and packaging.

Model answer

  • Application source repos build images; a separate deployment repository (or one per team) holds desired state, so CI commits don't trigger app builds and access can differ.
  • Per service: a Helm chart (existing ones) or a Kustomize base, with envs/dev|staging|prod overlays or values files containing only differences.
  • A platform repository for cluster add-ons (ingress, cert-manager, logging, policies), versioned and pinned.
  • CI renders every service for every environment and validates with kubeconform and policy checks.

Rubric

Look for separation of app code and deployment state, base-plus-differences per environment, and rendering and validation in CI.

Describe the Argo CD structure.

Model answer

  • One AppProject per team restricting source repos, destination namespaces and allowed kinds (no cluster-scoped resources); a platform project for add-ons.
  • An ApplicationSet per team with a Git directory generator (one Application per service directory) × a cluster generator; an add-on ApplicationSet targets clusters by label, so a new region gets everything automatically.
  • Sync policy: automated with prune and selfHeal; production syncs automated too, since approval happens in the PR; ignoreDifferences for HPA-managed replicas.

Rubric

Strong answers use projects for isolation, ApplicationSets for scale, cluster labels for add-ons and consistent sync policies.

Describe ordering and safety.

Model answer

  • Migrations as PreSync hook Jobs (idempotent, expand-and-contract); sync waves for config before workloads.
  • selfHeal on, kubectl write access in production limited to a break-glass role; OutOfSync alerts.
  • prune: true with Prune=false annotations on stateful resources (PVCs, namespaces) and review of deletions in PRs.

Rubric

Look for hooks for migrations, enforced drift correction with break-glass access, and protection against accidental deletion.

Describe secrets.

Model answer

  • External Secrets Operator with a cloud secret manager; Git holds ExternalSecret references only; per-team secret paths and IAM permissions.
  • Secret scanning in every repository and a policy rejecting kind: Secret in deployment repos; rotation runbook for leaks.

Rubric

Strong answers keep only references or encrypted values in Git and back that up with scanning and policy.

Describe promotion.

Model answer

  • CI publishes images by digest; a promotion tool or job opens PRs bumping the digest in dev automatically, in staging after dev checks pass, and in production after staging checks (smoke, e2e, soak) pass.
  • Production PRs require approval from the owning team; merge triggers the sync; rollback is reverting the PR.
  • Deployment history (which digest in which environment, with linked test results) is visible in Git and the promotion tool.

Rubric

Look for digest-based promotion gated on recorded checks, with approvals and rollback via Git.

Open in the app to mark lessons complete, take notes and track your progress.

Was this page helpful?