When to Reuse a Helm Template and When to Fork It

This is the decision I am examining: the boundary between common deployment structure and service-specific commands such as celery-low.

Context

I reused a common Deployment template for most services, but gave celery-low a specialized command template where its runtime behavior differed.

The decision mattered because Forcing every service into one universal template can hide important behavioral differences.

Options I consider

Option A — keep the simplest current behavior. This minimizes moving parts and is often the right choice while proving a migration path.

Option B — introduce a stronger abstraction immediately. This can improve long-term consistency, but it also adds another system to debug before the underlying workload contract is stable.

Option C — keep the simple implementation, but make the boundary explicit and define the trigger for revisiting it. This is often my preferred migration posture.

Decision criteria

values.yaml + templates -> rendered manifest -> ArgoCD/Kubernetes

Why the Voiceware implementation is useful signal

The repository tells me what was actually chosen at that point in the project. It does not force me to argue that the choice is universal. Infrastructure decisions are contextual: an early test cluster, a production environment, and a multi-team platform may reasonably choose different levels of abstraction.

Trade-offs I would write into the ADR

The primary downside is the failure mode already identified: Forcing every service into one universal template can hide important behavioral differences. The primary reason to keep the decision is the lesson: Reuse stable infrastructure shape; allow explicit specialization where process semantics differ.

I would also record what would make me revisit the decision: traffic growth, stronger availability targets, additional environments, security constraints, release complexity, or operational pain that the current model can no longer absorb cheaply.

Revisit triggers

• Render the chart before sync.
• Fail early when required values are absent.
• Use defaults only when a default is genuinely safe.
• Keep conditionals shallow and test both branches.
• Treat rendered YAML as a build artifact worth reviewing.

A good infrastructure decision is not one that never changes. It is one whose assumptions are visible enough that the team knows when it should change. The goal is not more Kubernetes. The goal is less ambiguity.