Continuous Build is not Continuous Integration
Automated builds have become a cornerstone of agile development. Every time a developer checks in a change, a tool like Cruise Control checks out all the sources, builds everything, runs all the unit tests and reports back with immediate feedback. This cycle has become known as Continuous Integration, due to the seminal paper by Martin Fowler and Matt Foemmel, but this is something of a misnomer. It is better described as Continuous Build. (Their use of “integration” was about integrating all the bits of software that the various programmers in a team would traditionally be working on in isolation from one another, only to bring together and spend days or weeks getting to work. Practices such as pairing and automated builds have all but eliminated this form of integration hell, at least on agile projects.)
However, delivering an application is more than just writing and testing software. The code lives in a container or application server, which runs in an operating system, on hardware, on a network, behind a firewall, connected to other machines, services and components, which may themselves be inside containers or application servers, and so on across your application, across your enterprise and maybe out into the wide world to other enterprises and other servers. (more…)
