How would you set Helm chart granularity policy across a platform of many services and teams?

### Derive the policy from the property, not from fashion The defensible way to answer this is to start from what Helm makes the release mean. A release is the unit of rollback (`helm rollback` takes a release and a revision, never a component), the unit of failure (one status covers the whole rendered manifest), the unit of concurrency (a pessimistic lock refuses a second in-flight operation), and the unit of history (one revision counter, one `--history-max` window). Four properties people care about are welded to one boundary. Therefore the boundary should be drawn where those four answers agree — which is normally around one thing that changes for one reason, has one owner, and can be reverted without anyone's permission. That yields a default and an exception rather than a doctrine: **one release per independently deployable unit**, with umbrellas allowed where the bundle *is* the deployable unit. ### Name the legitimate umbrella cases explicitly A policy that only forbids gets ignored. Enumerate what still qualifies. A product shipped to an installer you do not control — the whole point is one artifact, one version, one command. An ephemeral stand-up: CI environments and per-branch preview stacks, where a full system install and a full teardown are the operation, and where a shared failure costs nothing because the environment is disposable. A tight, single-owner cluster of components that are meaningless apart and always version together. Anything else defaults to its own release. Also name the anti-case, because it is common: an umbrella used as a table of contents, so that somebody can run one command and get the platform. That is a real need, but it is a composition need, and satisfying it with a release boundary charges the org rollback granularity forever. ### Budget for what the default costs The granularity decision is only half the design; the other half is what replaces the umbrella's conveniences. **Composition.** Something has to install fifty releases in a sane order and know which environments get which. That is a pipeline or a GitOps controller such as Argo CD or Flux, and choosing it is part of the granularity decision, not a later detail. If the org has no such layer, splitting first and composing later is how you get a platform nobody can stand up from scratch. **Shared configuration.** The `global` block was a real feature. Its replacement is an owned artifact — a common values file or a shared helper chart — plus something that guarantees every release actually consumes the current one. Without that, the failure mode is silent drift: one release still points at a decommissioned registry host because nobody re-ran it. **Ordering and prerequisites.** The umbrella implied an order it never really provided. Splitting forces you to make prerequisites explicit — shared infrastructure installed as its own release ahead of applications, and applications that tolerate a missing dependency through retries rather than assuming startup sequence. **Operational surface.** Fifty releases mean fifty histories, fifty locks and fifty things to observe. That is mostly a feature (each is answerable on its own) but it needs tooling: a single view of release status across the fleet, and alerting on releases stuck in a failed or pending state, which nobody misses when there is only one. ### Decide who chooses At platform scale the interesting question is not the rule but who applies it. Two workable models. Central: the platform team owns chart layout, teams get a generated release per service, and deviation requires a conversation. Federated: teams own their charts against a published rule and a checklist, and the platform team owns only the shared-infrastructure releases and the composition layer. Central produces consistency and a bottleneck; federated produces velocity and drift. The usual answer is federated with a small set of non-negotiables — every release has exactly one owning team, shared infrastructure is never bundled into an application release, and every chart declares its owner and cadence — and a periodic review of the outliers rather than a gate on every change. ### Make it observable, then let evidence move the boundary Granularity is not a one-off decision; it is a boundary that drifts as the system grows. Instrument the things that reveal drift: deploys blocked or queued behind another team, unrelated services reverted by an automatic rollback, how far back each release's history actually reaches, and time from merge to running per service. Review those numbers quarterly. A release whose history covers half a day, or that reverts services belonging to three teams, has outgrown its boundary regardless of what the policy document says. ### Sequence any change Finally, own the migration shape, because the failure mode is a big-bang cutover. Move one component at a time, noisiest or most foreign-lifecycle first — typically shared infrastructure. Adopt live objects into the new release before removing the component from the umbrella, since removing it first makes the next umbrella upgrade prune those objects and that is downtime. Keep the umbrella shrinking, and let it end up as either nothing or a genuinely small, single-owner bundle. Being able to say that sequence, and what you would *not* split, is what distinguishes a policy from an opinion.