GitOps CI/CD with Argo CD

What this diagram shows

This diagram illustrates a GitOps-driven continuous integration and deployment pipeline where source code changes trigger automated builds, artifacts are versioned, and configuration changes are promoted through git repositories before Argo CD syncs them to Kubernetes clusters. The flow moves from developer commits through a CI system (Jenkins, GitHub Actions, or GitLab CI) that produces container images, then updates a configuration repository with new image references. Argo CD monitors the config repo, detects drift between desired state in git and the live cluster state, and automatically synchronises deployments. This creates a single source of truth in git, full auditability via commit history, and rollback capability by reverting commits.

Key components

• Source Repository — Holds application code and triggers CI pipeline on commit events.
• CI/CD Engine — Builds, tests and pushes container images to a registry on successful pipeline completion.
• Container Registry — Stores versioned container images and provides pull access to Kubernetes clusters.
• Configuration Repository — Stores Kubernetes manifests (YAML, Helm, Kustomize) and tracks all deployment state changes as commits.
• Argo CD — Continuously monitors the configuration repository and synchronises the live cluster state to match the desired git state.
• Kubernetes Cluster — Runs the deployed application workloads and reports actual state back to Argo CD.
• Update Mechanism — Automatically commits new image references or config changes into the configuration repository after CI completes.

When to use it

Use this template when you need full audit trails of all infrastructure and application changes, want to treat kubernetes configuration as code with git-based versioning, require rollback by reverting commits, or need to enforce consistency across multiple environments. This approach suits teams practising infrastructure as code, those needing compliance visibility, or organisations with strict change control requirements. It is particularly valuable for teams running multiple clusters where config promotion through environments (dev, staging, production) must be traceable and reversible.

Common mistakes

• Committing secrets or credentials directly into the configuration repository instead of using external secret management systems like Sealed Secrets, HashiCorp Vault, or cloud-native equivalents.
• Allowing manual kubectl apply commands to bypass Argo CD, creating drift between git and the cluster that Argo CD cannot detect or reconcile.
• Storing the configuration repository and source code repository as a single monorepo without clear separation, making it difficult to manage deployment cadence independently from code release cycles.

Adapting it to your system

Replace the named CI system with your existing platform (GitHub Actions, GitLab CI, Jenkins, or CircleCI). Point the configuration repository to your chosen git host. Configure the image update mechanism to use tools like Flux Image Update Controller, ArgoCD Image Updater, or a custom scripted push to match your branching strategy (trunk-based, environment branches, or pull request workflows). Adjust the sync policy in Argo CD from automatic to manual if you prefer explicit approval before cluster changes. Add promotion stages between repositories if your workflow requires staging approval before production deployment.