Managing Components and Dependencies

In one sentence

You would assume applications get split into components for "clean architecture" or "reuse." The chapter's primary reason is far more practical: to get builds and feedback back under ten minutes. And it puts the cost on the table in the same breath — the moment you split, you lose the most valuable property continuous delivery has: one commit, one full verification. The whole back half of the chapter is about buying that property back with a dependency graph, an artifact repository, and one integration pipeline.

Glossary

Where it sits

This chapter belongs to Part III, "The Delivery Ecosystem," after Chapter 11 on infrastructure and Chapter 12 on data. It is where the book pushes "always releasable" down into the structure of the code itself. It follows from Chapter 3 (continuous integration: trunk must stay buildable at all times) and Chapter 7 (the ten-minute commit stage budget), and leads into Chapter 14 on version control and branching. The real-world questions it maps onto: monorepo or many repos, how to pin versions in Maven / Gradle / npm, and who exactly verifies a combination of microservice versions.

What problem it solves

Compress everything continuous delivery argues for into one line and you get "trunk is always releasable." By Chapter 13 that line has run into two walls.

The first wall is the large-scale change. Replacing an ORM, swapping a payment gateway, moving from home-grown auth to OAuth — work like this runs two or three weeks, sometimes months, and the code sits half-finished throughout. The traditional move is a feature branch in seclusion, merged at the end. But merge pain grows superlinearly with how long the branch lives: a one-week branch merges in fifteen minutes; a three-month branch takes several people several days, and afterwards nobody will vouch that it runs. That is the release-day hell of Chapter 1, moved into the code.

The second wall is build duration. Chapter 7 budgets ten minutes for the commit stage, because past ten minutes people start batching up their commits and continuous integration quietly dies. But codebases grow: a few hundred thousand lines with a few thousand tests routinely goes from an eight-minute build to a forty-minute one within a year or two. At that point a developer gets three or four trustworthy answers per day and the whole discipline of Chapter 3 collapses.

What happens if you ignore both? They lead to the same place: trunk stops being releasable — either because a long-lived branch is permanently "nearly done," or because a build nobody will wait for teaches everyone to route around the pipeline.

The core, properly explained

1. Before splitting anything: treat "always releasable" as a hard constraint

The chapter does not open with a decomposition strategy. It opens with three ways to protect releasability without touching the structure at all.

① Hide new functionality until it is finished. The code can merge to trunk and ship with every release — you simply do not wire up the entry point. As far as users are concerned it is code that can never be reached. "The feature isn't done" stops being a reason not to release.

② Make all changes incrementally. Break one large change into a series of small ones, with a hard test: stopping and releasing after any one of them must be safe. If that is not true, you have not really broken it up yet.

③ Branch by abstraction. The most useful trick in the chapter. The name comes from Paul Hammant, and one of this book's authors, Jez Humble, later wrote it up in his own right.

2. Branch by abstraction: "branching" on trunk

To replace a large part of a system without creating a version-control branch, five steps: ① introduce an abstraction layer over the part being replaced; ② change the rest of the system to depend only on that abstraction (usually the most laborious step, and the most valuable); ③ write the new implementation beneath the abstraction, alongside the old one; ④ point the abstraction at the new implementation, ramping by user or by traffic if you want; ⑤ once you are confident, delete the old implementation — scaffolding comes down when it is done, and often the abstraction goes with it.

The counterintuitive part: the act of branching has been moved out of version control and into the code. The repository holds one trunk and everybody integrates every day; the coexistence of two implementations is carried by an abstraction layer that compiles, tests and ships. Unlike a long-lived branch, its merge risk is smeared across every commit rather than saved up for one bad week.

The costs are real too. During the transition the codebase carries two implementations, which is harder to read and doubles some test surface. And if the abstraction covers only part of the old implementation's usage, the remaining call sites are back doors around the layer — and the whole scheme fails on switchover day.

3. Dependencies and dependency hell

Dependencies come in two flavours: build-time (needed to compile — a utility library) and runtime (needed only when running — a database driver). Almost all of the trouble is about versions.

The disease the book names is dependency hell — DLL hell on Windows, JAR hell in the Java world. Its classic shape is the diamond dependency: your application uses components A and B; A requires version 1.0 of some library and B requires 2.0 of the same one, while the class loader (or DLL loader) at runtime can only hold one. When the two versions are not API-compatible there is no clean answer — somebody has to give way, by downgrading, by adapting the code, or by isolating the loading.

The remedy is to manage your libraries. The book accepts two routes: check the binaries straight into a lib/ directory in version control (simple, absolutely reproducible, at the price of a bloated repository and entirely manual upgrades), or use declarative dependencies plus an artifact repository (the Maven / Ivy approach: easy upgrades, at the price of state living outside version control). Whichever you pick, one rule in this chapter is not negotiable: pin your versions, and never use dynamic ones like "give me the latest." This is not fastidiousness — dynamic versions make builds irreproducible: the same source is green today and red tomorrow while you changed nothing, and the cost of diagnosing that is brutal.

4. Components: when to split, and what the pipeline becomes

The book's definition of a component is roughly: a reasonably large-scale code structure with a well-defined API that could in principle be swapped for another implementation. Bigger than a class, lighter than an independently deployed service.

Its list of good reasons to split is deliberately short: builds and tests take too long; different parts change at very different rates (a reporting module untouched for a year need not rebuild alongside a checkout module that changes three times a week); you genuinely need reuse across products; the team is large enough to need clear ownership boundaries; some part must be deployed or scaled independently. The book explicitly rejects splitting to make the architecture look nicer, and its stance is: live with one pipeline until it stops working, then split off only the pieces you truly need.

After the split, the pipeline changes shape: each component gets its own pipeline, publishing versioned binaries into an artifact repository; downstream components build against upstream artifacts pulled from it; and an integration pipeline picks one specific set of versions (say A-12, B-7, C-3), assembles them and runs acceptance tests. One hard constraint applies: the dependency graph must be acyclic.

Triggering is a genuine problem here. Trigger every downstream the instant an upstream goes green, and a graph of a few dozen components turns one change into a build storm. Never trigger automatically, and a breaking change hides until the day somebody upgrades by hand — by which point dozens of changes have piled up and nobody can say which one broke it.

5. Cautious optimism: dependency edges that back themselves out

The chapter's answer to that dilemma is cautious optimism: stop treating "pinned" and "always latest" as a binary choice, and give every edge of the dependency graph one of three states.

• Static — pinned to a version; new upstream releases change nothing until a human upgrades it.
• Fluid — always takes the newest upstream version that passed its pipeline.
• Guarded — fluid by default, but when a new version turns the downstream red, the edge automatically falls back to the last known good version and freezes there until someone fixes it.

One honest caveat: this mechanism rarely exists off the shelf. In 2010 you largely had to build it into your own build tooling, and today it is still mostly assembled from custom logic on a CI platform — it is better remembered as a design idea than as a switch you can flip.

6. Circular dependencies and the artifact repository

Circular dependencies — A depends on B, and B depends back on A — are, in the book's words, probably the nastiest dependency problem. Most build tools simply refuse them. If you truly must get out of one in the short term, there is the build ladder: build B against the old A, then build the new A against that B, climbing one rung at a time. But the book is blunt that this is a stopgap, and the right fix is to refactor the cycle away — usually by extracting whatever both sides depend on into a third component.

The artifact repository is where Chapter 5's "build your binaries only once" lands in a componentized world. What it must do: hold every binary the pipelines produce, retrieve them by version, remember which commit each artifact came from, and — when an artifact is promoted from test to production — re-label it rather than rebuild it. Conversely, binaries do not belong in version control: they can be regenerated from source, and repositories were not designed for large files.

Key trade-offs

Table 1 · Three ways to make a large-scale change

Table 2 · Managing library dependencies

Table 3 · Version strategies across components (the chapter's central table)

Table 4 · Should this become a component?

Why it matters / in real systems

The loudest argument in the industry today — monorepo versus many repos — is just Table 3 in modern dress: one end says "every component builds from the latest source and is verified together," the other says "every edge is pinned and each part evolves on its own." This chapter costed out both ends in 2010, before either word existed.

Three things do need updating. First, incremental builds and remote caching in Bazel and Gradle have partly removed the chapter's primary reason to split — you can now plausibly keep one enormous repository and still get feedback inside ten minutes. Second, the lockfile ecosystem (package-lock.json, Gemfile.lock, go.sum) is the industrialized answer to pinning, and bots like Dependabot and Renovate are the industrialized answer to fluidity; together they land remarkably close to cautious optimism. Third, microservices pushed components all the way to independently deployed units, which turns this chapter's dependency-graph problem into a service-contract problem — consumer-driven contract testing does exactly the job of the integration pipeline.

Pitfalls and open arguments

• Reading branch by abstraction as "just add an interface." The interface is not the point; routing every call site through it is. Any call site you miss is a back door around the layer that blows up on switchover day. And the layer is temporary scaffolding — leave it standing and in a few years it is a hollow shell nobody dares touch.
• Believing componentization makes builds faster. After a split, total build time across all components usually goes up; what shrinks is the critical path. You are buying "one change need not verify everything" and paying by deferring integration risk.
• Splitting too early. The chapter's position is unambiguous: live with one pipeline first. Five components in a small team means five times the version-coordination cost for no benefit.
• The lure of dynamic versions. LATEST and ^1.2 look convenient and make builds irreproducible. But pinning everything has its own cost — security fixes lag. The modern answer is lockfiles for reproducibility plus upgrade bots to stay current, a combination the 2010 book did not have.
• Cautious optimism is expensive to implement. Lovely concept, almost no off-the-shelf tooling; most teams fall back to "pin, then upgrade in batches." Honestly, this section's value is mostly as a frame for thinking.
• Period limits. The book is from 2010: no Docker, no Bazel remote caching, no mature lockfile ecosystem, and "artifact repository" mainly meant Nexus or Artifactory — whereas today the most important one is the container registry. More fundamentally, "builds are too slow," the chapter's primary reason to split, has been meaningfully weakened by modern build tooling, so its criteria deserve recalibration.
• Still unsettled. Monorepo versus many repos has no agreed answer. The chapter lays out both, but its tone clearly leans toward "don't split unless you must" — a lean that Google's practice supports at enormous scale and that holds for small teams too, though not necessarily for product lines that need independent release cadences.

Takeaways