16.6 · Multi-hour CI, affected-module builds, caching, and Tuist and Bazel
When an app has hundreds of modules and many teams, the build becomes a product of its own: the question is not “how do I compile this” but “what must I rebuild and retest for this change”.
Mental model. Do the minimum work the change requires: build and test only the affected modules, reuse results with a cache, and run the rest in parallel.
Scaling the build
Affected-module builds, caches, and tools for large graphs.
- A CI pipeline takes hours on a large modular app. How do you analyse and cut it: affected builds, caching, parallelism, and Tuist or Bazel?
Start by describing the pipeline as data: stages (resolve dependencies, build, unit tests, UI tests, lint, archive, upload), their durations, what each depends…
More in Modularization & SPM
- 16.1 · Targets, products, modules, and access across module boundaries
- 16.2 · SPM, CocoaPods, Carthage and XCFrameworks, and shipping binaries
- 16.3 · Static and dynamic linking, duplicate symbols, and the dependency graph
- 16.4 · Build settings, configurations, xcconfig, and compile times
- 16.5 · Resource bundles, localisation in modules, and feature flags
- 16.7 · Version rules, pins, conflicts, unsafe flags, mirrors and inspecting the graph
- 16.8 · Conditional settings, platform minimums, language modes, traits and plugins
- 16.9 · What really crosses a module boundary: inlinable bodies and imports