CI Pipeline

Origin & evolution

Grady Booch named the idea. In *Object-Oriented Analysis and Design with Applications* (2nd edition, 1994) he used the phrase "continuous integration" to describe integrating the parts of a system frequently as it grew, sparing teams the one late big-bang integration that had been the norm. Booch supplied the term; he did not yet mean the rapid, automated rhythm the practice later took on.

That rhythm came from Extreme Programming. Kent Beck and the team on the Chrysler C3 project in the late 1990s pushed integration to the limit, merging and rebuilding many times a day so the codebase stayed in a working state continuously. Beck's *Extreme Programming Explained* (1999) put continuous integration among XP's core practices. Martin Fowler then codified it for a wider audience in his article *Continuous Integration*, first published in 2000 and substantially revised in 2006, which set out the now-standard rules: a single source repository, an automated and self-testing build, commit to mainline every day, and keep the build fast.

The terms multiplied as the practice matured, and they are worth keeping straight. Continuous integration validates every change against the shared mainline. Continuous delivery, formalised by Jez Humble and David Farley in *Continuous Delivery* (2010), extends the pipeline so that every validated build is kept in a deployable state, with a human deciding when to release🚢ReleaseProduct SpecificationA shipped version of the productView reference →. Continuous deployment📤DeploymentEngineeringA deployment eventView reference → goes one step further and ships every passing change to production automatically, with no human gate. The pipeline is the spine running through all three: the same path to production, with the line drawn at a different point.

How it works in practice

An engineer on a logistics product pushes a change to the route-optimiser. The pipeline wakes on the commit. Stage one installs dependencies⛓️DependencyTeam & OrganisationA cross-team or system dependencyView reference → and compiles in 90 seconds. Stage two runs 1,400 unit tests in parallel across four workers, two minutes. Stage three lints, type-checks, and scans dependencies for known vulnerabilities🔓VulnerabilitySecurityA known vulnerabilityView reference →. Stage four builds a container image, tags it with the commit SHA, and pushes it to the registry as the build artifact🏺Build ArtifactEngineeringA build output (binary, container image)View reference →. Eight minutes after the push, the engineer has a green tick and a versioned image ready to deploy. A colleague who pushed an incompatible change to the same module twenty minutes earlier already saw red, fixed it, and re-pushed, so the two changes never collided in anyone's working copy. That is continuous integration doing the one thing Booch named it for.

CI pipeline vs. its neighbours

• Build artifact is the output the pipeline produces: the compiled binary, container image, or package. The pipeline is the process; the artifact is the durable thing it hands off to deployment. One pipeline run yields one artifact, identified by the commit it was built from.
• Deployment is what happens after the pipeline blesses an artifact: installing that version onto an environment. CI ends at "this build is good"; deployment begins at "put this good build somewhere".
• Code repository💾Code RepositoryEngineeringA source code repositoryView reference → is the source the pipeline reads from and the trigger that starts it. The repository holds the truth; the pipeline acts on every change to that truth.

In the graph

In the Unified Product Graph, the CI pipeline is the engine node of the engineering region, the thing every other delivery concept routes through. A product🧬ProductStrategyThe product being created, the root of the graphView reference → connects via product_built_by_ci_pipelineProductbuilt byCI Pipelinehierarchy, recording the path by which the product is assembled. The pipeline's outputs and actions are explicit edges: ci_pipeline_produces_build_artifactCI PipelineproducesBuild Artifacthierarchy for what it makes, ci_pipeline_deploys_serviceCI PipelinedeploysServicecross-domain for what it ships, and infrastructure_component_built_by_ci_pipelineInfrastructure Componentbuilt byCI Pipelinehierarchy for the infrastructure-as-code it provisions. Modelling the pipeline as a first-class node, with its inputs and outputs as edges, turns "how does code reach production here?" into a path you can walk, freeing the answer from one engineer's head.