GitOps CD Developer

CD half of the GitOps loop: a root Application spawns child Applications, each of which renders a shareable Helm chart with per-environment values and a chosen rollout strategy. ArgoCD sees the diff, syncs, self-heals, prunes — no kubectl apply from a CI pipeline.

When to use

• The user wants to set up ArgoCD / Flux for the first time.
• The user wants to design an App-of-Apps tree so one root manages many envs / instances / tenants.
• The user wants a sharable Helm chart their other repos can consume (multi-runtime, multi-env).
• The user wants to choose / wire a rollout strategy: RollingUpdate, Recreate, blue-green, canary.
• The user wants values-dev.yaml / values-staging.yaml / values-prod.yaml laid out cleanly.
• A task chain ends in "and ArgoCD picks it up automatically".

Pairs with gitops-pipeline-developer (the CI half — produces images and updates values.yaml). Together: CI pushes the image + tag + digest to GitOps; CD reconciles cluster state from the GitOps repo.

The release loop in one paragraph

CI produces a signed image and writes the new tag + digest into a values.yaml in a GitOps repo. The root ArgoCD Application in the management cluster watches a folder of child Application templates; each child points at the GitOps repo and renders one or more workloads via a shared Helm chart. ArgoCD's automated sync sees the values-file change, performs helm template, diffs against the live cluster, applies changes with ServerSideApply, and reports Healthy / Synced. Self-heal undoes drift; prune removes resources no longer in git. The cluster's state is, by definition, what's in git.