Integration Build or End-to-End Increment¶
Continuous integration — instantiates Concurrent Cross-Functional Integration
Frequently recombines the teams' partial outputs into a running end-to-end increment and runs cross-functional cases, so interface and workflow failures surface now instead of at final assembly.
An Integration Build is the recombination engine of the archetype: at a small cadence it actually assembles the teams' partial outputs into a running end-to-end increment and runs cross-functional cases against it, so the failures that only appear when work is combined surface early and cheaply. Its defining property is frequent, whole-system recombination — not the per-interface checking of the Interface Control Document and Contract Test, but the assembled system exercised together. It is where interface defects genuinely appear across streams, get routed to owners, and get logged; and it produces the readiness signal that the Integrated Readiness and Release Review later consumes.
Example¶
An autonomous-vehicle program has separate teams for perception, prediction, planning, controls, and safety. Each team's own tests are green — but the behaviors only interact once combined. Every night an integration build assembles the latest of each stack into a full system and runs it against a battery of cross-functional scenarios on recorded sensor logs and a closed-course rig, including adversarial cases like a pedestrian at dusk or a mid-drive sensor dropout.
Tonight's build surfaces that a new perception model's timing shift makes the planner brake late — a defect invisible to any single team's tests. It is captured, routed to the two owning teams, and retested on the next build; the pattern is logged in the interface defect register so the timing contract gets tightened. Unsafe scenarios run only in the isolated rig, never on public roads.
How it works¶
- Assemble partial outputs into a real end-to-end increment at a small cadence — daily or nightly — so each recombination is small.
- Run cross-functional and boundary cases in a realistic environment, isolating unsafe tests from live operation.
- Capture failures, route them to the owning streams, and retest; publish the evidence and a readiness signal.
- Log interface defects and rework with root cause, so recurring cross-stream failures drive changes to the work design, not just patches.
Tuning parameters¶
- Integration cadence — how often you recombine; more frequent means a smaller blast radius per failure but more infrastructure cost.
- Case coverage — happy-path only vs. adversarial and boundary breadth; coverage is what separates a green build from a working system.
- Environment fidelity — how realistic the integration context is; higher fidelity catches more, costs more.
- Repeatability — a fully automated, repeatable build vs. a manual merge that can't be reproduced.
- Defect-routing discipline — how fast a captured failure gets an owner and a retest.
When it helps, and when it misleads¶
Its strength is converting late big-bang integration risk into a steady drip of cheap, early failures[n1] — and making "every component green, whole system red" visible while there is still time to fix it.
Its failure modes are happy-path-only testing (a green build over a broken reality), manual unrepeatable merges, an unrealistic test context that passes things production won't, and — despite the name — a late big-bang integration anyway. The classic misuse is gaming the build green by disabling the cross-functional cases that keep failing, which converts the signal into decoration. The discipline that guards against it is representing real context, keeping the build repeatable, and never disabling a case just to stay green.
How it implements the components¶
continuous_integration_and_cross_functional_test_plan— it recombines partial outputs and runs cross-boundary cases at the smallest useful cadence, as a whole-system slice (the per-interface contract-test slice belongs to the Interface Control Document and Contract Test).interface_defect_and_rework_register— captured failures, their root cause, affected streams, rework, and closure are logged here so recurring interface defects feed the work design.
It reveals defects continuously but does not define or version the interface contracts it tests against (Interface Control Document and Contract Test) — it consumes them — nor gate the final release (Integrated Readiness and Release Review) or resolve the one hard blocking constraint (Cross-Functional Swarm on Integration Constraint).
Related¶
- Instantiates: Concurrent Cross-Functional Integration — the build is where partial work is continuously recombined and tested.
- Consumes: Interface Control Document and Contract Test supplies the interface contracts the increment is tested against; the Shared System Model or Digital Thread supplies versioned inputs.
- Sibling mechanisms: Interface Control Document and Contract Test · Integrated Readiness and Release Review · Cross-Functional Swarm on Integration Constraint · Shared System Model or Digital Thread · Dependency and Change Notification Board · Cross-Functional Design Review · Big-Room Planning or Concurrent Set-Based Workshop · Integrated Product or Service Team
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Integration Build or End-to-End Increment operates as a bounded trial, probe, simulation, or rehearsal that generates evidence from performance because it frequently recombines the teams' partial outputs into a running end-to-end increment and runs cross-functional cases, so interface and workflow failures surface now instead of at final assembly
Independent corroboration: The frozen evidence defines Integration Build or End-to-End Increment as 'Frequently recombines the teams' partial outputs into a running end-to-end increment and runs cross-functional cases, so interface and workflow failures surface now instead of at final assembly', so its operative form is Experiment, Test & Rehearsal.
Nearest alternative: Protocol, Workflow & Routine — Frequent recombination and realistic cross-functional cases make this an ongoing integration test rather than only a handoff routine.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Convergent development
Present-day reach: Specialized
Rationale: Frequent recombination into a running end-to-end increment derives directly from continuous integration and agile software practice.
Related originating lineages:
- Organizational & Management Science — Cross-functional cadence and whole-outcome ownership materially shape the process beyond code merging.
Review resolution: Both independent reviews place the primary lineage in computer_science. The queued differences (origin_mode_disagreement) concern secondary metadata rather than primary provenance. The final retains organizational_management only where a reviewer supplied a formative-lineage rationale; this does not convert downstream applicability into origin. origin_mode=convergent because the reviewers document independently established or materially co-developing traditions. domain_reach=specialized records application breadth separately from provenance.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Continuous Integration (the term coined by Grady Booch and popularized in agile practice by Kent Beck and Martin Fowler): integrate work frequently so each recombination is small and conflicts surface early, rather than accumulating divergence into a painful late merge. ↩