Skip to main content
Version: 0.1.124

Bundles

A bundle is a named group of finished features, assembled onto one branch so they can be tested together before any of them merges.

The problem it solves​

Features are implemented one at a time, each on its own branch, each verified on its own. That tells you each works in isolation. It does not tell you they work together, and the interactions between two features are exactly where the interesting failures live.

Merging them one by one to find out is the slow version of this, and it puts the discovery after the merge rather than before it.

What a bundle is made of​

  • Members — the features included.
  • A base branch — what the bundle is assembled on top of.
  • A branch of its own, holding the combination.
  • A UAT target, where the assembled combination runs.

Once assembled, the bundle is verified as it would land, not as it currently stands — the question being answered is what happens when this combination reaches the integration branch.

Staleness​

A bundle carries a staleness indicator, and it matters. A bundle is a snapshot of a set of features at a moment; if a member feature has been re-implemented since, or the base branch has moved, the thing you tested is no longer the thing that will merge.

Check staleness before you rely on a bundle's result. A stale bundle's green run is a statement about code that no longer exists.

When to use one​

  • Several features that touch the same area, finished around the same time.
  • A release's worth of work, verified as a set before it lands.
  • Two features you suspect interact, tested together deliberately rather than discovered later.

If features are independent and touch nothing in common, a bundle adds ceremony without adding information.