GitOps with ArgoCD and Helm: Auditable Releases in Regulated Environments

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 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.

The GitOps model

The fix I reach for is GitOps: the desired state of every cluster lives in a Git repository, and a reconciliation controller (I use ArgoCD) continuously compares that declared state against what's actually running, and corrects any drift automatically. Helm charts template the Kubernetes manifests, so a single chart describes an application while environment-specific values files supply the differences between dev, staging, and production. Nothing reaches a cluster except through a change to Git, and every change to Git is a reviewed merge request. That single constraint, no direct cluster access ever, is what turns "trust me" into "here's the commit."

Multi-environment promotion

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 is a git revert, not a scramble to remember the previous Helm release number. Because ArgoCD reconciles continuously, the moment the revert lands, the cluster follows, with no separate rollback tooling and no manual intervention. This also means 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 CI

GitOps handles what happens after a change is approved, but I still want confidence in what's being proposed. I run build, test, and security scanning 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 immutable tag, never by latest, so what's described in Git is exactly what gets deployed, with no ambiguity about which build is running.

Takeaways

• Declarative desired state in Git beats imperative deployment scripts for anything that needs to be audited later.
• No manual cluster access. Every change to running infrastructure is a reviewed, merged commit.
• Promotion and rollback become Git operations: a merge or a revert, not bespoke tooling.
• Security scanning belongs in CI, before a change is even proposed for deployment.
• The audit trail falls out of how the deployment model works, so it is not a separate system to maintain.