Some corrections about the early days of Continuous Integration
UPDATE: Added Netscape’s Tinderbox which I forgot about and started even earlier than CruiseControl.
I recently read an article by Greg Foster on the Graphite blog: From the 80’s to 2024 — how CI tests were invented and optimized (graphite.dev).
Some corrections about the early days…
Extreme Programming means testing all the time, not just some of the time.
Foster mentions how Extreme Programming had code authors write their own tests.
But self-testing was an opt-in process, relying on authors to diligently run local tests before merging. What’s more, the test’s success was dependent on the author’s local computer running it rather than a source-of-truth server. Codebases were still at risk of breaking the next time a build was cut and test suites executed.
There are a few issues with this characterization of testing in Extreme Programming:
- Testing is not opt-in. See Test Driven Development.
- Testing is not just done on your local computer. See Continuous Integration.
Automating build tests started earlier than at Google in 2003.
While Google started automating its build tests in 2003, the engineering industry took slightly longer to do the same.
Microsoft was doing Daily Build and Smoke Test by at least 1996.
The first Extreme Programming teams were doing “Continuous Integration Relentless Testing” around 1998.
CruiseControl came before Hudson; Tinderbox came before CruiseControl
In 1997, Netscape built what seems to be the first continuous integration server, Tinderbox.
In 2001, I became a committer on the CruiseControl continuous integration build server, based on an internal ThoughtWorks tool called “build monkey”. For a time, I’d argue it was the most popular CI server until Hudson (aka Jenkins) came along in 2004.
