CI/CD¶
Continuous integration and delivery pipelines, GitOps-driven deployment workflows, and automated release management for Kubernetes and cloud-native environments.
Topics¶
| Tool | Description |
|---|---|
| ArgoCD | Declarative GitOps CD tool for Kubernetes — centralized hub-and-spoke engine with rich UI, RBAC, and multi-cluster support. CNCF Graduated. |
| FluxCD | Decentralized GitOps toolkit (GOTK) with modular controllers for source, Helm, Kustomize, and image reconciliation. CNCF Graduated. |
Comparisons¶
| Comparison | Scope |
|---|---|
| GitOps Tools Comparison | ArgoCD vs FluxCD — architecture, operational model, multi-tenancy, and use-case fit |
Landscape¶
The CI/CD space has undergone a fundamental shift from imperative push-based pipelines toward declarative pull-based GitOps models, where the desired state is stored in Git and a reconciliation agent ensures the live cluster converges to match. This evolution was formalized by the CNCF GitOps Working Group's OpenGitOps principles (v1.0, 2022), establishing a vendor-neutral definition that both ArgoCD and FluxCD implement.
Meanwhile, progressive delivery techniques — canary releases, blue-green deployments, and feature flags — have moved from optional add-ons to first-class primitives, with tools like Argo Rollouts and Flagger automating metric-driven promotion decisions. Multi-tenancy remains a critical architectural concern as platform teams adopt shared GitOps control planes serving dozens of application teams, requiring careful RBAC, namespace isolation, and policy enforcement.
Platform Engineering Convergence
The broader trend is toward "platform engineering" pipelines where CI/CD is one composable capability within an Internal Developer Platform (IDP), often orchestrated through Backstage or Port service catalogs. In this model, developers interact with golden paths that abstract pipeline configuration, while platform teams own the underlying ArgoCD/FluxCD infrastructure.
The push-vs-pull debate is not binary — many organizations run hybrid models where a CI system (GitHub Actions, GitLab CI, Tekton) builds artifacts and pushes them to a registry, then a GitOps controller pulls the updated manifest and reconciles the cluster. Supply chain security is increasingly embedded in the pipeline itself, with Sigstore cosign signing OCI artifacts, SLSA provenance attestations, and Tekton Chains recording tamper-proof build metadata.
Key Concepts¶
GitOps¶
A set of practices where the entire system's desired state is versioned in Git, and automated agents reconcile live infrastructure to match that declared state. The four OpenGitOps principles are: declarative configuration, version controlled, automatically applied, and continuously reconciled. Both ArgoCD and FluxCD implement these principles but differ architecturally — ArgoCD uses a centralized Application CRD with a web UI, while FluxCD uses decoupled controllers (source, kustomize, helm) composed via GitRepository and Kustomization CRDs.
Reconciliation Loop¶
The core mechanism in GitOps controllers — a continuous loop that compares the desired state (Git) against the actual state (cluster), computes a diff, and applies corrective actions to eliminate drift. Both ArgoCD and FluxCD default to polling intervals (typically 3-5 minutes) but support webhook-triggered reconciliation for faster convergence. The loop follows a consistent pattern: fetch source, render manifests (Kustomize/Helm), diff against live state, apply changes, report status.
Drift Detection¶
The ability to detect when live cluster state diverges from the declared Git state, whether caused by manual kubectl edits, external controllers, or admission webhook mutations.
ArgoCD surfaces drift as "OutOfSync" status in its UI and supports automated self-healing (auto-sync with prune enabled).
FluxCD emits Kubernetes events and can be paired with notification controllers for alerting to Slack, Teams, or PagerDuty.
Drift Sources
Common drift sources include: manual kubectl apply or kubectl edit commands, Horizontal Pod Autoscaler modifying replica counts, admission webhooks injecting sidecars, and external operators modifying resources they own. A robust GitOps setup must account for these by excluding managed fields from diff calculations.
Progressive Delivery¶
An umbrella term for deployment strategies that gradually shift traffic to a new version while validating health via automated analysis. Canary deployments route a small percentage of traffic first; blue-green maintains two full environments and switches atomically. Argo Rollouts and Flagger both integrate with service meshes and ingress controllers to automate promotion or rollback based on Prometheus metrics, error rates, or latency thresholds.
Key integration points:
- Argo Rollouts: Supports Istio, Linkerd, AWS ALB, NGINX, and Ambassador for traffic splitting. Uses AnalysisTemplates to query Prometheus, Datadog, or custom webhooks.
- Flagger: Works with Istio, Linkerd, Contour, Gloo, and Gateway API. Uses MetricTemplates with built-in Prometheus and CloudWatch support.
Multi-Tenancy¶
The practice of operating a single GitOps control plane across multiple teams, namespaces, or clusters with strong isolation guarantees. ArgoCD achieves this via AppProjects with source/destination restrictions and RBAC policies; FluxCD uses Kubernetes-native RBAC with per-namespace Flux installations and cross-namespace source references. Both approaches require careful design to prevent privilege escalation.
Open Questions¶
- How does the emerging Kubernetes Gateway API affect progressive delivery tooling, given that Argo Rollouts and Flagger historically relied on Ingress and service mesh APIs for traffic splitting?
- As GitOps adoption scales to hundreds of clusters, what are the practical limits of pull-based reconciliation latency, and when does a hybrid push+pull model become necessary for time-sensitive deployments?
- Will the convergence of CI and CD into unified platforms (e.g., Tekton Chains for supply chain security, or Flux's OCI artifact support) reduce the need for separate CI systems like GitHub Actions or Jenkins?