Reusable deployment conventions

Defaults carry operating decisions

A convention is a choice a team agrees to repeat. For example, a consistent ownership label tells an operator whom to contact. A supported readiness probe tells Kubernetes when a Pod can receive traffic. The useful question is not “Does every manifest look the same?” but “Does this default help us operate the service?”

A convention should have a reason

Useful MicroBank conventions include ownership labels, explicit image identity, resource requests, tested health endpoints, and stable Service names. Each solves a specific support problem. A template containing every Kubernetes object is harder to operate if several of those objects have no defined purpose.

Kustomize is the chosen application configuration mechanism here. Helm remains useful for packaging third-party controllers. Avoid having Helm and Argo CD independently own the same release objects. When Argo CD renders a Helm chart, it manages the resulting desired resources; that workflow differs from separately running Helm upgrades.

Conventions are not business checks

Sync waves can order groups of resources within a sync operation. They do not by themselves verify that MicroBank settled a transaction or implement a production canary. Likewise, a PodDisruptionBudget influences voluntary disruptions; it is not a substitute for spare capacity, compatible storage, or application correctness.

Keep a template change log. A changed default can affect every adopting service, so test it against representative fixtures and one local deployment before offering an upgrade. Existing generated copies do not automatically receive a later template fix.

Review three defaults as a consumer

Consider a template upgrade that changes a Service selector. The YAML may render successfully, yet the Service can lose all intended endpoints. Review the rendered selector against Pod labels; then verify routing in the disposable local deployment. Formatting tests alone cannot answer that question.

As a practice review, choose one existing convention in your MicroBank base. Describe its old value, proposed value, consumer impact, check and recovery. Keep a copy of both renders and compare only the relevant fields. If you cannot explain why the change is needed, do not add it just because a production checklist mentions it.

A generator makes a copy at a point in time. Unless you implement an update mechanism, changing its source later does not update every previously generated repository. Release notes and a migration path are part of maintaining the convention.

Try it

Choose three conventions for the current base. For each, state the operating question it answers, its test, and an exception process. For example, require an ownership label, test its presence and value, and block onboarding until an actual owner is assigned.

Render before and after a template change and inspect selectors, image references, Secret references, and resource count. Run the saved-case check separately from manifest checks; each verifies a different part of the deployment.

Checkpoint and revision

Explain how a consumer learns of a template upgrade, adopts it, and recovers if it fails. A default becomes a supported contract only when someone maintains its behavior and migration path.

Compare your reasoning

A PDB limits some voluntary disruption; it cannot manufacture capacity or fix a broken application. A readiness probe and a transaction test ask different questions. Choose defaults with tests for their actual purpose rather than treating their presence as a reliability certificate.

Sources

Argo CD Helm behavior↗, Sync waves↗, Disruption budgets↗.