CI/CD and GitOps Integration

Driving Helm through GitHub Actions and GitLab CI pipelines, integrating with Argo CD and Flux for GitOps, and using helm template for diff-based deployment workflows.

Overview

Push versus pull

Integrating Helm into CI/CD pipelines and GitOps workflows is where chart knowledge becomes production engineering. Two fundamentally different models exist: push-based, where a CI pipeline runs helm upgrade against the cluster, and pull-based GitOps, where Argo CD or Flux watches a Git repository and continuously reconciles the cluster to match it.

Push (CI runs helm upgrade) — Simpler — None until the next deploy — No
Pull (GitOps controller) — Controller to run — Continuous — Automatic

> [!WARNING] In the push model, a manual edit to a Deployment or ConfigMap goes unnoticed until the next deploy.

Push-based deploys from CI

GitHub Actions and GitLab CI are the dominant CI platforms for push-based Helm deploys.

> [!TIP] --atomic --wait --timeout makes the pipeline report success only when the deployment is healthy, and roll back on failure.

Pull-based GitOps controllers

Argo CD and Flux both have first-class Helm support, but they use Helm in very different ways.

Argo CD — Application resources reference a chart; renders with helm template and applies the manifests — No
Flux — HelmRelease CRDs reconciled by helm-controller with the Helm SDK — Yes

> [!IMPORTANT] The key interview distinction: Argo CD renders and applies; Flux runs real Helm install and upgrade under the hood.

Key concepts

Push-based deployment: CI pipeline (GitHub Actions, GitLab CI, Jenkins) runs helm upgrade --install directly. Fast to set up, no controller needed. No continuous reconciliation — drift from manual changes is not detected or corrected.
Pull-based GitOps (Argo CD / Flux): A controller watches a Git repository containing the desired state (chart reference, version, values). On change, the controller renders the chart and reconciles the cluster. Drift from the desired state is automatically corrected. Every cluster change is a Git commit — full audit trail.
Argo CD Helm rendering model: Argo CD renders charts with helm template and applies via kubectl. Does NOT run helm install — no Helm release Secrets are created. helm list shows nothing for Argo CD-managed releases. Helm lifecycle (rollback, history) is replaced by Argo CD sync/rollback.
Flux HelmRelease (native Helm semantics): Flux's helm-controller uses the Helm SDK (helm install/upgrade under the hood). Full Helm release tracking: helm list shows releases, helm history works. Closer to native Helm semantics than Argo CD. HelmRelease CRD declaratively defines chart, version, and values.
helm diff plugin: databus23/helm-diff plugin that shows a diff between the current release state and what helm upgrade would apply. Analogous to terraform plan. Used in CI for preview steps and PR checks to show reviewers exactly what cluster changes a values or chart version change would produce.
OIDC for CI authentication: GitHub Actions and GitLab CI support OIDC (OpenID Connect) to authenticate to Kubernetes clusters and cloud providers without storing long-lived credentials. The CI provider mints a JWT; the cluster or cloud provider validates it. No AWS_ACCESS_KEY_ID or kubeconfig secrets needed in CI.

When to use it

Push-based CI: smaller teams, simple deploys, when GitOps controller infrastructure is not yet in place
Argo CD GitOps: when drift detection and continuous reconciliation are required, or for multi-cluster management
Flux GitOps: when composable, controller-per-function architecture is preferred or when HelmRelease native semantics matter
helm diff in CI: for preview-before-deploy workflows, particularly for change-averse production environments

Interview questions

Write a GitHub Actions workflow step that deploys a Helm chart to a Kubernetes cluster securely.
Explain how Argo CD deploys a Helm chart and how it differs from running helm install.
How do you update a deployed application's image tag in a GitOps workflow?
How does Flux HelmRelease differ from Argo CD Application for Helm deployments?
How do you implement a helm diff step in CI for production safety?
What authentication pattern should CI use to deploy to Kubernetes, and why?