GitOps with ArgoCD and Helm: Auditable Releases for Regulated Industries

An auditor wants to know which software version was running in production on a given day, and who approved it. In many teams that starts a tedious search through logs, tickets, and people's memories. With GitOps the answer is always in Git, and a faulty release can be undone with a single revert.

Key takeaways

• With GitOps, the desired state of every Kubernetes cluster lives in Git, and ArgoCD corrects any drift automatically.
• Without direct cluster access, every change to running infrastructure is a reviewed, merged commit.
• Promotion and rollback become Git operations: a merge or a revert, with no bespoke tooling.
• Security scans belong in the CI pipeline, before a change is even proposed for deployment.
• The audit trail comes out of the deployment model itself and does not need to be maintained as a separate system.

Why push-based deployments fail audits

I still see teams deploying to Kubernetes by running kubectl apply from a laptop, or by letting a CI pipeline push straight into a cluster on every merge. Both work, until someone asks the question every regulated environment eventually asks: what was running in production on a given date, who approved it, and can you prove it?

With push-based deployments, the honest answer is usually "we're not entirely sure." The cluster's actual state and the record of intended state drift apart the moment a manual kubectl edit or an emergency hotfix bypasses the pipeline.

Auditors don't accept "check the deployment logs" as a satisfying answer, and neither should I.

How GitOps works with ArgoCD and Helm

The fix I reach for is GitOps. The desired state of every cluster lives in a Git repository. A reconciliation controller, in my case ArgoCD, continuously compares that declared state against what is running in the cluster and corrects any drift automatically.

Helm charts and values files per environment

Helm charts template the Kubernetes manifests. A single chart describes an application, and environment-specific values files supply the differences between dev, staging, and production.

The one rule: no direct cluster access

Nothing reaches a cluster except through a change to Git, and every change to Git is a reviewed merge request. That single constraint is what turns "trust me" into "here's the commit."

Promotion from staging to production

With this structure, promoting a release between environments stops being a deploy script and becomes a Git operation. The same chart version moves from staging to production by merging a values-file change that bumps the image tag or config for that environment.

Rollback with git revert

Rollback is a git revert, not a scramble to remember the previous Helm release number. Because ArgoCD reconciles continuously, the cluster follows the moment the revert lands. There is no separate rollback tooling and no manual intervention.

Commit history as release history

The promotion history is the commit history. I can point at a pull request and show exactly when a version reached production and who approved it.

Security stages in the CI pipeline

GitOps handles what happens after a change is approved. I still want confidence in what is being proposed.

So build, test, and security scanning run as distinct stages in GitLab CI before an image or chart is even eligible for a values-file bump. Dependency scanning, container image scanning, and policy checks all gate the pipeline.

Built artifacts are pushed to a central registry and referenced by an immutable tag, never by latest. What's described in Git is exactly what gets deployed, and there is no doubt about which build is running.

What this means for your company

In regulated industries, the question "who approved what, and when?" will come, at the latest in your next audit. An uncertain answer then costs time and trust, and reconstructing the history ties up exactly the people who should be working on your product. On top of that there is a concentration risk: if only a few individuals know what runs where, that knowledge is missing precisely when those people are on holiday or leave the company.

With GitOps, that evidence is a by-product of everyday work. Your team documents nothing extra, because every change is created as a reviewed commit anyway. Releases also become more predictable, since a faulty update is undone with a revert and no manual emergency work in the cluster. I describe how I set up release processes and deployments on AWS on the page about AWS costs and scaling.