H.7 Integration
Integration is the state machine that turns candidate changes into a shared source state. Tests are evidence inside that machine; branches, queues, selection, admission, and recovery decide how the evidence controls movement.
Trace A Candidate Through The State Machine
H.7.1 Integration Models establishes the authoritative branch, convergence
frequency, history semantics, and maximum divergence. For a candidate based on
revision B, H.7.2 Evidence Portfolio names the local, presubmit,
post-submit, scheduled, static, integration, performance, and security evidence
that protects distinct risks.
H.7.3 Evidence Selection narrows that portfolio from changed scope, invalidators,
uncertainty, and acceptable miss cost. H.7.4 Change Admission decides whether the
result is complete and fresh enough for a prospective state such as B+C.
Unknown selector output is therefore a state requiring a named fallback or risk
decision, not a successful check.1
Admission changes authoritative source state. It does not promote an artifact or change a running environment; those transitions belong to H.11.5 Promotion.
Add Coordination Only Where It Pays
H.7.5 Merge Queue orders candidate states when collision and recovery risk
justify the wait. H.7.6 Speculation may evaluate B+C1, then
B+C1+C2, in parallel, but every result must retain the exact ordered state;
failure or mutation of C1 invalidates dependent evidence. This added machine
is useful only after serial admission is a measured bottleneck.
H.7.7 Flakiness repairs, explicitly quarantines, replaces, or retires evidence that cannot describe the tested state reliably. H.7.8 Main Recovery classifies a shared-main incident, assigns bounded coordinating authority, communicates affected scope, and chooses revert, fast fix, or another repair. The coordinator routes domain work without becoming every component's owner. Repository-service restoration belongs to H.10.2 Service Reliability, while product and runtime repair belongs to H.11.7 Delivery Recovery.
Design integration as explicit candidate states and transitions. Each result needs a purpose, scope, identity, freshness rule, and owner; queues and speculation optimize that contract, while flakiness and recovery determine whether it remains trustworthy under failure.
Footnotes
-
Keeping main green in a monorepo — admission evidence, merge coordination, and recovery for shared main ↩
Sections in this chapter · 8
Choose authoritative branches, convergence frequency, merge-history semantics, and activation separation from divergence and recovery needs.
Assign purpose, protected scope, environment, owner, latency, cost, reliability, and response to complementary evidence classes.
Select evidence from change risk, protected scope, invalidators, uncertainty, and acceptable miss cost.
Change authoritative source state only under explicit evidence completeness, freshness, uncertainty, and known-good-state rules.
Operate ordered prospective-state admission only where reduced collision and recovery risk justify queue delay and compute.
Validate parallel hypothetical repository states with exact identity, dependency invalidation, bounded capacity, reuse, and failure attribution.
Restore decision value to unreliable evidence through detection, explicit quarantine, repair, replacement, or retirement.
Recover shared main through classification, bounded authority, communication, repair, handoff, and learning.
