Helm Charts and Kubernetes Deployment Automation: What a DevOps Engineer Builds in 2026

1. Helm Charts for Each Service

A Helm chart is created for each service in the cluster. A well-structured chart includes: templates/deployment.yaml (pod specification, containers, environment variables, resource limits), templates/service.yaml (Kubernetes service for intra-cluster traffic), templates/ingress.yaml (external traffic routing), templates/hpa.yaml (HorizontalPodAutoscaler), templates/configmap.yaml (non-sensitive configuration), and templates/secret.yaml or ExternalSecrets integration for sensitive values.

The chart is parameterised: image repository, image tag, replica count, resource requests and limits, environment variables, and ingress hostnames are all values that differ between environments and are supplied at deploy time rather than hardcoded in the templates.

2. Values Files Per Environment

A values file per environment (dev, staging, production) contains the overrides for that environment. Staging values: replica count 1, smaller resource requests, staging hostnames. Production values: replica count 3, standard resource requests, production hostnames, production-specific environment variables. The same chart deploys correctly to both environments using the appropriate values file, eliminating the risk of environment-specific YAML drift.

3. Helm Repository or GitOps Structure

Charts are stored either in a Helm repository (OCI-based, hosted in ECR, ACR, or GCR) or in a Git repository used by ArgoCD or Flux. For the OCI repository approach: helm push packages and versions each chart, and helm pull retrieves it. For the GitOps approach: the chart directory lives in Git alongside the values files, and ArgoCD reconciles the cluster state to the Git state continuously.

4. CI/CD Pipeline Integration

The CI/CD pipeline (GitHub Actions, GitLab CI, or Azure DevOps) calls Helm at the deployment step. Typical pipeline structure: build and push Docker image with the new tag, run helm upgrade with the new image tag as a set value, wait for the deployment rollout to complete, run smoke tests. If the smoke tests fail, helm rollback is called automatically. The image tag is the only value that changes on each deployment; everything else comes from the values file.

5. Helm Hooks for Pre and Post-Deployment Tasks

Helm hooks run jobs at specific points in the deployment lifecycle. Common uses: database migration job runs as a pre-upgrade hook before the new application version starts (ensures the database schema is ready), smoke test job runs as a post-upgrade hook to validate the deployment, data cleanup job runs as a post-delete hook when a release is removed. Hooks give the deployment pipeline structure that kubectl apply sequences cannot provide.

What ArgoCD adds to Helm

With Helm only: a developer runs helm upgrade from a CI/CD pipeline when they push code. ArgoCD monitors the Helm chart values in Git and automatically syncs the cluster to match the Git state. If someone manually changes a pod's replica count using kubectl, ArgoCD detects the drift and reverts to the Git-defined state within minutes.

With ArgoCD: the cluster state is always what Git says it should be. Manual kubectl changes are overwritten. The cluster is self-healing by definition.

The ArgoCD application model

ArgoCD uses Application CRDs to define what to deploy and where. Each service gets an ArgoCD Application that specifies: the source (Git repository URL, path, and branch), the destination (Kubernetes cluster and namespace), and the sync policy (automatic sync, self-heal, and prune options). A DevOps engineer creates Application manifests for each service and configures sync policies appropriate for each environment (staging: auto-sync, production: manual promotion).

Promotion between environments

With Helm and ArgoCD, environment promotion is a Git operation rather than a CI/CD command. Promoting a service from staging to production means updating the image tag in the production values file and merging the PR. ArgoCD detects the change in Git and syncs the production cluster. The complete audit trail for every production change is in Git history, not in CI/CD logs that may expire.

Helm and GitOps engagement scenario

Cost at $22/hour

What is delivered

Helm charts for 3 to 5 services

3 to 5 days: $528 to $880

Chart per service, values files per environment, rollback configured

Helm charts for 6 to 10 services

5 to 8 days: $880 to $1,408

Full chart library, shared library chart for common templates

Helm + CI/CD pipeline integration (GitHub Actions)

2 to 3 days: $352 to $528

Pipeline calls helm upgrade with image tag, rollback on failure

ArgoCD setup and Application configuration

3 to 5 days: $528 to $880

ArgoCD deployed, Application CRDs per service, auto-sync for staging

Full GitOps stack (Helm + ArgoCD + environment promotion)

8 to 14 days: $1,408 to $2,464

Complete GitOps deployment system with staging and production promotion

Monthly retainer (Helm + cluster management)

$3,200/month

Chart maintenance, new service onboarding, ArgoCD management

What replaces kubectl apply after Helm and ArgoCD are set up

Before: developer SSHes into CI server, runs kubectl apply -f deployment.yaml

No version tracking. No rollback. Environment drift possible.

After (Helm + CI/CD pipeline):

Developer pushes code. Pipeline builds image. Pipeline runs:

helm upgrade service-a ./charts/service-a --set image.tag=v1.2.3 -f values/prod.yaml

Full release history in helm history service-a.

Rollback: helm rollback service-a 2 (one command, takes 30 seconds)

After (Helm + ArgoCD GitOps):

Developer updates image.tag in production values.yaml, opens PR, gets review, merges.

ArgoCD detects the Git change and applies to production automatically.

Full audit trail in Git history. No CI/CD log expiry. Manual changes auto-reverted.