CodeHistory.org
FIELD NOTE / 2026.09.213 MIN READ / 5 SOURCES

The Minds Behind Continuous Integration and Delivery – 7 People Redefining Software

Seven practitioners and toolmakers helped compress software delivery from infrequent integration events into automated build, test, and deployment pipelines.

Written byTheo MercerEDITOR · CODEHISTORY RESEARCH DESKRESEARCHED / CITED

TL;DR

Seven practitioners and toolmakers helped compress software delivery from infrequent integration events into automated build, test, and deployment pipelines. [1][2]

Why you should read it anyway

CI/CD changes risk by changing batch size. When teams integrate, test, and deploy small changes frequently, failures are easier to localize and releases stop being giant synchronization events. Automation converts delivery from a fragile ritual into a repeatable technical capability.

Imagine where Continuous Integration and Delivery would be without them

Without these people and tools, automated builds and releases would still emerge, but common CI conventions, Jenkins-style automation, deployment pipelines, and Continuous Delivery as a named discipline would have taken longer to standardize.

Time Estimate of how many years we would be hindered without them for human progress

Editorial counterfactual estimate: 4–8 years. This is not a measured historical fact. It is an editorial estimate of how much slower the field might have matured without this cluster of people, institutions, practices, and tools.

The 7 people behind Continuous Integration and Delivery

1. Martin Fowler

Why they matter: helped define and popularize Continuous Integration as the practice of integrating into a shared mainline frequently and verifying each integration with an automated build and tests. His writing made CI’s feedback-loop logic accessible to mainstream development teams.[1]

2. Jez Humble

Why they matter: co-authored Continuous Delivery and helped articulate deployment pipelines, production-like environments, automated acceptance testing, and the idea that software should remain releasable throughout its lifecycle.[2]

3. David Farley

Why they matter: co-authored Continuous Delivery and contributed a systems-oriented engineering model for build, test, deployment, and feedback automation. His work emphasized that reliable releases emerge from designing the delivery process itself as an engineered system.[3]

4. Paul Duvall

Why they matter: authored Continuous Integration and helped codify practical techniques for automated builds, testing, inspection, database integration, and deployment. His work made CI implementation concrete for teams adopting the practice.[4]

5. Kohsuke Kawaguchi

Why they matter: created Hudson, which later became Jenkins, giving teams a flexible open-source automation server for builds, tests, and delivery pipelines. Jenkins became one of the most widely recognized pieces of CI/CD infrastructure.[5]

6. James Duncan Davidson

Why they matter: created Apache Ant, which made portable build automation a standard part of Java development. Build automation is a prerequisite for dependable continuous integration because the same repeatable process must run across developer and CI environments.[1]

7. Mike Clark

Why they matter: was an early advocate and author on pragmatic build automation, testing, and continuous integration. His writing helped establish the idea that builds should be fast, repeatable, automated, and treated as core development infrastructure.[2]

How they each differ from one another

Fowler explained CI practice; Humble and Farley extended it through the production deployment pipeline; Duvall codified implementation; Kawaguchi built Jenkins; Davidson enabled portable Java builds with Ant; Clark promoted disciplined build automation.

Final Take

Continuous delivery is the engineering of confidence. Every automated build, test, environment, and deployment step exists to answer one question faster: can this change safely become real software for users?

RESEARCH / PROVENANCE

Works Cited

5 SOURCES
  1. 01
  2. 02
  3. 03
  4. 04
  5. 05

CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.

Contribute / Corrections

Improve the record.

Use this moderated submission form to suggest a correction, provide a source, challenge a priority claim or identify a missing contributor. Submissions are treated as research leads, not automatically published comments.

Submit a research lead

Please do not submit confidential material or claims you cannot support.