I have about five years of experience as a DevOps engineer. Earlier in my career, I worked mainly with service-based companies, which gave me a broad foundation in deployments, CI/CD pipelines, cloud platforms, and different technology stacks. For the past two years, I've worked on enterprise products running on-premises, using both unmanaged Kubernetes and managed services such as EKS, GKE, and OKE.
I recently joined a product company whose AWS infrastructure is managed with Terraform. The applications and supporting services are deployed through Argo CD using Helm charts, subcharts, values files, and dependencies. I understand the underlying Kubernetes YAML and generally know what the resources are doing, but I'm still struggling to understand the structure and upgrade process when chart versions, application versions, dependencies, and supporting tools all need to change together.
Because this is a live production product rather than a development project, there is very little room for mistakes and changes often need to be made quickly. What would be the best way to learn Helm in this kind of environment? I'm especially looking for guidance on understanding existing charts, tracing values and dependencies, and safely testing and rolling back upgrades.
2 Answers
For production upgrades, avoid changing everything at once. Pin the chart, application, and dependency versions in a staging environment, then upgrade one layer at a time. Before syncing, render the manifests and use a diff tool such as helm diff to see exactly what will change. Check the chart’s values, Chart.yaml, lock file, and dependency versions together so you know which versions are coupled.
Also make sure the rollback path is clear before making the change. Test the upgrade in staging, monitor the rollout and dependent services, and keep the previous known-good chart revision available for a quick Argo CD rollback.
Read the existing repository from the outside in: start with the Argo CD Application, identify the chart path and values files, then inspect Chart.yaml and any dependency declarations. After that, trace each important value into the templates and see whether it is overridden by environment-specific files or Argo CD parameters.
It can also help to render the chart locally with helm template and compare that output with the manifests running in the cluster. For learning, recreate a simplified version of the setup in a personal cluster. AI tools can help explain unfamiliar templates, but verify their suggestions against the chart documentation and the actual rendered manifests.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures