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.
Join Anton Weiss and Arthur Berezin from PerfectScale by DoiT for a free workshop on Aug 26 @ 11am ET, as they break down how reliability-first Kubernetes optimization makes real cost reduction possible — through workload-aware guardrails that enable continuous, autonomous optimization without the production risk.
This live Kubernetes session shows you practical ways modern environments can optimize Kubernetes at scale.
👀 Remote Jobs
Railsware is hiring a Senior DevOps Engineer
Remote Location: Worldwide
Joist AI is hiring a SRE Engineer
Remote Location: India
📚 Resources
Looking to promote your company, product, service, or event to 50,000+ Cloud Native Professionals? Let's work together. Advertise With Us
🧠 DEEP DIVE USE CASE
How to Structure Kubernetes Configurations for Multiple Environments
A team running dev, UAT, and production clusters usually starts the same way: one YAML file per resource, copied three times, with a handful of values changed in each copy, replica count, image tag, resource limits, ingress hostname. This works for the first few services. By the twentieth service, a single database connection string change means finding and editing the same line in sixty different files, and missing one of them is how a stale config reaches production undetected.
Kubernetes itself has no opinion on how configuration should be organized across environments, so this problem gets solved entirely by tooling built on top of it, and the two dominant answers, Helm and Kustomize, solve it in fundamentally different ways.
Helm Architecture
Helm treats a Kubernetes application as a package.
Helm CLI (Client layer): The entry point where operators run
helm install,helm upgrade, orhelm rollback. It talks directly to the cluster’s API server.Charts (Packaging layer): Versioned bundles that hold templates, default values, and metadata. These capture how an app should run, not just static manifests.
Chart Repositories (Distribution layer): Centralized storage and discovery for charts. Think of it like a package registry for Kubernetes apps.
Templating Engine (Rendering layer): The piece that merges chart templates with the supplied
values.yamlto generate manifests tailored to an environment.Kubernetes API (Execution layer): The endpoint where Helm pushes the rendered manifests for actual deployment on the cluster.
Promoting One Chart Across Environments
The real value of Helm for multi environment work is not templating, it is separating a chart's structure from its per environment configuration entirely. The chart defines what the application looks like, a values file defines what it looks like in a specific environment.
Use Git Flow to turn chart changes into repeatable releases. Work in a feature branch, open a PR, and let CI build a versioned chart once the PR merges to main.
The pipeline lints the chart, runs helm template for a dry render, bumps the chart version, and publishes the package to your chart registry or cloud provider registry. Promotion is done by deploying the same artifact with different values files.
A common path:
A developer opens a pull request against a feature branch. Once a reviewer approves and merges into main, GitHub Actions builds and publishes the chart to a Helm repository, then immediately pulls that same published chart to deploy into the development cluster.
Staging and production follow the identical pattern, each with its own GitHub Actions workflow pulling the same published chart version and deploying it into its own cluster. The chart artifact itself never changes between development, staging, and production, only the values passed alongside it differ.
Rollback is one command because Helm tracks release history: helm rollback ecom-app <revision>.
🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)
Upgrade to Paid to read the rest.
Become a paying subscriber to get access to this post and other subscriber-only content.
UpgradePaid subscriptions get you:
- Access to archive of 250+ use cases
- Deep Dive use case editions (Thursdays and Saturdays)
- Access to Private Discord Community
- Invitations to monthly Zoom calls for use case discussions and industry leaders meetups
- Quarterly 1:1 'Ask Me Anything' power session
