TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities and articles.
Claude is a superpower if you know how to use it correctly.
Discover how THE CODE's Playbook to AI can elevate both your productivity and creativity to get more things done.
Learn to automate tasks, enhance decision-making, and foster innovation with the power of AI.
IN TODAY'S EDITION
🧠 Use Case
How to Use Helm Charts for Kubernetes Deployments
👀 Remote Jobs
Social Discovery Group is hiring a Senior DevOps Engineer
Remote Location: Worldwide
Metabase is hiring a Senior SRE/DevOps Engineer
Remote Location: Worldwide
Powered by: Jobsurface.com
📚 Resources
If you’re not a subscriber, here’s what you missed last week.
To receive all the full articles and support TechOps Examples, consider subscribing:
🛠 TOOL OF THE DAY
Mercek - A local-first desktop IDE for Amazon ECS.
Mercek puts your services in one window so you can check rollouts, metrics, logs, cost, and dependencies without switching tabs and accounts.
🧠 USE CASE
How to Use Helm Charts for Kubernetes Deployments
Deploying an application to Kubernetes means writing multiple YAML files (a Deployment, a Service, a ConfigMap, maybe an Ingress). For a single environment this is manageable. The moment you need to deploy the same application to development, staging, and production with different image tags and replica counts, raw YAML becomes hard to maintain and easy to get wrong.
Helm is the package manager for Kubernetes. It adds a templating layer on top of Kubernetes manifests so you define your application once and supply different values per environment. A Helm chart is the packaged unit that contains those templates along with default configuration values that get substituted at deploy time.
How the Helm Workflow Works
A chart developer creates the chart and uploads it to a Helm repository, which is an HTTP server hosting packaged chart archives. A Helm user adds that repository to their local Helm client, runs helm install, and Helm downloads the chart, merges the user supplied values with the chart defaults, renders the templates into Kubernetes manifests, and applies them to the cluster.
The deployment is tracked as a named release so it can be upgraded, rolled back, or removed as a single unit.
Helm Chart Structure
A Helm chart is a directory with a fixed structure. Each file has a specific role and Helm expects them in the right place.
Bitnami GitHub repo is a good source of Helm chart examples.
Chart.yaml is the chart's identity file. It holds the chart name, version, and description. The version follows semantic versioning and is what Helm uses to track releases in a repository.
values.yaml defines the default configuration values. Every configurable aspect of the chart (image name, image tag, replica count, service type, resource limits) lives here. When a user installs without supplying their own values, these defaults apply. When they supply overrides via a values file or --set flags, those override the defaults at the matching key.
values.schema.json is an optional JSON Schema that validates user supplied values before Helm renders any templates. If a user passes the wrong type or omits a required field, Helm rejects the install immediately rather than letting a misconfigured pod reach the cluster.
The charts/ directory holds sub charts for declared dependencies. Running helm dependency update downloads them here. When Helm renders your chart, it includes the sub chart manifests in the output, so a complex application with multiple components can be installed as one unit.
The templates/ directory holds the Go template files that Helm renders into actual Kubernetes manifests.
A deployment.yaml template references values like .Values.image.tag which Helm substitutes at install time.
A service.yaml does the same for the Service resource.
The _helpers.tpl file holds named template snippets, things like the app's full name and common labels that are reused across multiple template files to keep them consistent.
NOTES.txt is rendered and printed to the terminal after a successful install, giving users the commands they need to reach the application.
Releases and Rollbacks
Every helm install creates a numbered release stored as a Secret in the cluster. When you run helm upgrade with a new image tag, Helm renders the updated manifests, diffs them against the previous release, and applies only what changed.
If the upgrade fails, helm rollback restores the previous revision from the stored release history without needing the original chart files.
This is what separates Helm from running kubectl apply directly, where the cluster state is the only record of what was deployed.
When to Write Your Own Chart
For common infrastructure like databases, ingress controllers, and monitoring stacks, well maintained public charts are available on Artifact Hub / Bitnami GitHub repo and save significant effort.
For your own applications, writing a chart is the right move. It captures the deployment knowledge (ports, environment variables, health check paths, resource requests) in a versioned artifact that any team can use consistently across all environments.
THE CODE - Learn how to code faster with AI in 5 mins a day. Loved by 200k+ devs, engineers at Meta, Google, OpenAI, and more.
🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)
Looking to promote your company, product, service, or event to 49,000+ DevOps and Cloud Professionals? Let's work together.
