Skip to content

PATTERN Cited by 1 source

Tier topology as long-running branches

Definition

The tier topology as long-running branches pattern replaces separate database instances per environment (prod, staging, UAT, QA, perf, demo) with a single database parent and a hierarchy of long-running branches that represent each environment in the promotion path. Feature branches are ephemeral and descend from a tier; tiers are stable and have a declared parent-of chain that defines the promotion hierarchy.

This eliminates environment drift (every tier descends from the same parent), removes provisioning/patching overhead (branches are metadata operations), and makes schema diff between any two tiers a computable operation rather than a manual comparison of independent installs.

Mechanics

  1. A tier is a long-living branch with a declared parent in the promotion hierarchy
  2. A feature is an ephemeral branch that descends from a tier and gets cleaned up after merge
  3. The parent-of chain IS the promotion path — no separate promotion configuration
  4. Policy prevents transitions that contradict the parent chain (e.g., feature cannot merge directly to production)
  5. One pipeline definition covers all tiers (branch-aware, not tier-specific)
  6. Rollback is repointing the application to the pre-promotion snapshot branch

Benefits

  • No drift: every tier descends from the same parent; divergence is tracked as page-level diffs
  • Cost reduction: six instances → one parent with branches (sub-second creation, zero initial storage)
  • Cost attribution: Unity Catalog captures branch_id, project_id, endpoint_id automatically
  • Rollback in seconds: repoint to snapshot branch, no data migration

Anti-pattern

Maintaining separate database instances per environment with manual syncing, independent patching, and drift detection scripts. This approach scales linearly in ops cost with environment count.

Seen in

Last updated · 542 distilled / 1,571 read