Helm Chart Development for Deploying Applications in Kubernetes

Developing Helm charts for Kubernetes deployment: where it breaks

Until Helm charts exist, Kubernetes deployment rests on manual manifests and one engineer's memory. Someone remembers that in the test environment the image is tagged differently, while production needs a separate set of environment variables.

At the same time, changes are made via kubectl apply directly into the cluster, bypassing the repository—and the repository ends up not reflecting what actually runs.

Then the environments diverge. The difference between test and production accumulates in details: resource limits, replica count, external service addresses, enabled readiness checks, and the order in which ConfigMap and Secret are applied.

After a few weeks, no one can clearly say how the live cluster differs from what is described in the files, and moving any change turns into a separate task with a manual review.

The most expensive part is release rollback. The rollback command returns only what Helm remembers in its state—manual edits made after installation remain in the cluster and continue to break behavior.

The incident is investigated manually: they compare the history of applied manifests, cluster events, and pod logs to understand which change caused the failure.

The outcome is predictable: rollout takes hours, the result depends on who is on duty, and restoring the previous version is not a single command but an investigation.

We’ll break down how this is solved: what is described in charts, how values are separated by environment, and what makes release rollback reproducible.

What changes after moving to declarative deployment

After moving to declarative deployment, application state is described by values files rather than a sequence of manual actions.

The cluster is brought to the described form with a single command—and measurable metrics change: rollout time, downtime window, and the share of incidents caused by discrepancies between environments.

Rollout time is reduced: the templates are debugged, and only parameters change.

Rollback stops being a separate recovery operation—the previous release revision is stored alongside, and returning to it takes as long as a normal rollout, instead of manually assembling the manifests again.

A whole class of failures goes away—environment divergence. One set of templates and separate values files for test and production environments mean the differences are described explicitly in the repository, not held in the head of the engineer who edited the cluster manually.

Service downtime becomes predictable. Readiness checks do not let traffic into an unready container, the update policy defines how many instances are taken out of service at the same time, and pre-install jobs run before rollout begins.

For stateless services, the downtime window is reduced to zero; for data stores, it is calculated in advance and verified in the test environment.

Environment reproducibility no longer depends on who set up the environment and when: the same chart deploys a new environment in an identical form.

Hence the short checklist of effects—fast rollout and rollback time, no discrepancies between environments, a known downtime window, and repeatable configuration on every deployment.

Options for organizing releases: comparing approaches

The approach to rollout almost always grows out of the first working solution—and this is visible in the limitations that then accumulate. Below are four options that teams actually choose between when there are more applications than one cluster and more than one environment.

In practice, we rarely start with charts from scratch: first, manifest templates describe what is already being rolled out manually, so that the desired state matches the actual state.

Then shared pieces—network policies, secrets, queues—are moved into chart dependencies, and the application stops duplicating other services' files.

Custom rollout scripts are usually the last to disappear: they are replaced by a chart with helm lint checks and dry-run before applying. This provides predictable rollback to the previous revision and the same result across all environments.

Work stages: from manifest audit to handover

We work in iterations: each step ends with a verifiable artifact, and the next begins only after the previous one is accepted. This way, an error in the release scheme does not surface in production, where its cost is service downtime.

1. Service inventory and manifest audit. We collect everything deployed in the cluster, including what was installed manually. We split objects into those common to all services and those unique, and record duplicates and “drifted” values in individual environments—this is the map for future templating.
2. Release scheme design. We decide where there will be one umbrella chart and where there will be standalone charts, what lives as a dependency, and how values are inherited across environments. We agree on resource names so that a release of one service does not overwrite a neighboring one.
3. Template setup. We move repeated parts into shared fragments and describe the values schema with validation before applying. Annotations with configuration checksums address the situation where the application keeps running on old settings after an update.
4. Rollback verification. We learn to roll back consciously: we review revision history, migration and hook status, and understand exactly what will roll back with the application and what will remain. If a step does not return, we change the scheme rather than write an instruction.
5. Trial run in the test environment. We run the full cycle “install—update—rollback” in a test environment close to production in resource composition. The release is considered atomic: if a readiness check fails, the scheme returns to the previous revision on its own.
6. Documentation handover. We provide chart descriptions, a values schema with explanations, release and rollback procedures, and versioning rules. The documentation lives in the repository next to the templates, not as a separate file.
7. Team training and support for the first releases. We go through the first release with your engineers, review analysis of failed runs and values edits. After that, the team manages releases on its own—we remain available for scheme consultations.

Deliverables: charts, schemas, and regulations

The deliverables are not an archive with templates but a working system in which the customer can ship releases without our involvement. We hand over everything needed for building, checking, and rollout: from repository structure to instructions for the on-call shift.

• Chart repository with change history: a single source of truth for all environments, branching for releases, and review of edits through merge requests.
• Environment parameterization: test and production environments differ only by a values file, not by a copy of templates—divergence between environments stops accumulating.
• Dependency schemas: which charts are related to each other, what is pulled from the shared repository, where external services are, and the order in which they appear.
• Access policies: who edits production environment values, who has read-only access, how roles in the cluster are separated, and who approves changes.
• Release regulation: rollout sequence, mandatory checks before publication, and criteria under which a release is stopped.
• Rollback regulation: return to the previous revision with a single command, what happens to data and migrations, and how long it takes the environment to return to a working state.
• Deployment documentation and on-call shift instructions: typical failures, diagnostics, whom to escalate to, and what can and cannot be done manually.

Each item is agreed with the customer's team at acceptance, not simply handed over “in a folder.” The customer's engineers go through configuration review and a trial release on their own—after that, the deliverables are considered accepted.

Case study: release cycle on Helm was reduced from two days to an hour

Starting point

A service consisting of twelve components—API, workers, scheduled jobs, schema migrations—was deployed with a set of manual manifests duplicated across four environments.

Edits in one directory did not reach the others: divergences accumulated, and a release turned into a two-day ritual with manual file comparison.

Rollback took at least forty minutes and was performed by reverse-applying the same manifests—meaning every emergency carried the risk of a new error.

What we changed and what we got

We assembled parameterized Helm charts: a library chart with templates for Deployment, Service, Ingress, readiness probes, and autoscaling, and on top of it, thin service charts where only the image, limits, and environment variables remain in the values file.

Differences between environments are described by separate value sets, secrets come from an external vault, and they do not end up in the repository.

Before applying, templates are rendered and compared with the current release state, so a configuration error is caught before production.

A release is one apply command and up to an hour from merging an edit to a working environment, including running checks; manual steps went from three dozen to two.

Rollback takes minutes: a return to the previous release revision as a whole, not rebuilding a set of files from scratch.

A whole class of failures related to environment divergence is gone: configuration is described by a single source, and differences between environments are visible to the eye before applying.

What to do if manual manifests are already deployed in the cluster

There is no single right path: the choice depends on the number of services on manual manifests and how often they are edited.

The general principle is not to rebuild a working environment but to bring it to charts in such a way that services are not recreated and do not lose state.

Therefore, the first step is inventory: which objects were created manually, who changed them, and how the actual parameters differ from the original files.

Gradual migration is the most common option for a production environment. The chart is described so that object names, selector labels, and namespace match the current ones: then the system adopts existing resources under management instead of deleting and recreating them.

The first release is assembled from values that repeat the actual parameters, and only then do shared settings move into templates and subcharts.

Backward compatibility is checked before applying: comparing rendered manifests with the current cluster state and a trial run show exactly what will change.

Separately, we record which fields cannot be updated on a live object—they are edited during a maintenance window, not blindly during a release.

The migration strategy is fixed in the chart itself and in the release order: until all services are migrated, manual manifests are marked as frozen, and edits go only through the repository. This removes configuration drift and enables rollback of any service to the previous revision.

Technical concerns: questions about charts and environments

Engineers rarely doubt Helm itself—questions usually concern specifics: how secrets get into environments, what happens to pods during an update, and what will remain in the repository after handover. Below are short answers on each of these points.

Will the update happen without downtime, and how do we roll back?

Rollout uses a rolling update strategy: new replicas pass readiness checks before old ones are removed, and the unavailability window is limited by the disruption budget.

Schema migrations are moved into hooks and run before or after the release, so the database does not break midway. Each release is saved as a separate revision—rollback is a return to the previous version, not a manual edit of manifests.

How are templates checked, and what about support after handover?

Template rendering and values schema validation are run locally and in the build, and the result is compared with the current cluster state—you can see exactly what will change before applying. Errors surface in the branch, not in the production environment.

After handover, there remains a repository with charts, environment-specific value sets, checks, and a description of the release process; we provide support for an agreed period, and after that your team ships changes.

Let's discuss the task: we'll design a deployment scheme for your cluster

Preparation for the start begins with service inventory, not with writing charts: until the composition of applications and their dependencies is visible, any scope estimate will be approximate.

To discuss the task substantively, we will ask for a minimum of input data—usually one conversation and access to repositories are enough.

• list of services, their dependencies, and what is currently deployed manually in the cluster;
• target environments: how many there are, how they differ, and how values are overridden between them;
• requirements for rollback and update order—what may be restarted and what may not;
• secrets and configurations: where they come from, who owns them, and how they get into the cluster;
• image tagging strategy so that any version can be reproduced and rolled back;
• cluster limitations: quotas, network policies, storages, roles, and access rights;
• control points—who accepts the release and by what criteria they consider it successful.

In response, we will provide a scope estimate, a stage-by-stage work plan, and a deployment scheme: the structure of Helm charts, separation of values by environment, and the order of migrations and rollback.

Then we follow the plan and show the result on the very first environment, without waiting until the end of the work.

Describe your task—we will get back to you with an estimate and a plan.