||New Reviews| |Software Methodologies| |Popular Science| |AI/Machine Learning| |Programming| |Java| |Linux/Open Source| |XML| |Software Tools| |Other| |Web| |Tutorials| |All By Date| |All By Title| |Resources| |About||
Keywords: Software development processes, automated builds, development environments
Title: Continuous Integration
Author: Paul Duvall, Steve Matyas and Andrew Glover
Publisher: Addison Wesley
Verdict: Overall this book provides convincing arguments in favour of a comprehensive continuous integration process.
Like unit testing and automated builds, continuous integration is one of those development best practices that everyone can agree on, from the most extreme programmers to the most dogmatic of RUPistas. System integration - the moment when all of the different components of an application come together to produce a harmonious and pleasing whole - can be such a painful and difficult procedure that it's tempting to put it off until later. It's a lot of hassle, it takes so much time, there's always something missing and so… There you are on the eve of release, only to find that rather than software harmony, you've got massive discord and disaster.
The answer to these woes is not to put off integration until it's too late, but to automate it and to run it continually. Of necessity this entails some up-front investment in time and resources - even if you opt to use open source tools for an integration server, you're still going to require a dedicated box to run it on. Just as important, as this book makes plain, you're going to have to spend time building a 'clean' environment free of those hidden dependencies that lurk on developers' machines. At the very least, the 'it builds fine on my machine' conversations should be banished forever.
There are other benefits to be had too, and the first part of this book goes through these in some detail. Most are fairly obvious, but for those seeking ammunition to persuade others of the benefits there's plenty here to back up your arguments. It's important to understand that a continuous integration process can include much more than compiling and linking source code and libraries, it can include running unit tests, checking code for conformance to standards, deploying the application, running static analysis tools and so on.
While the first part of the book looks at principles and practices, the second part of the book looks in more detail at each of these major classes of integration: automated builds, database integration, unit testing, code coverage and so on. Where having an automated build that is triggered by changes to source checked into your source control database is the starting point, the author makes plain that this is only a beginning and that continuous integration should extend well beyond program code but also include changes to database schemas, running test suites and so on. The emphasis on database changes in particular is useful, as this is a notoriously difficult area to get right.
Despite the breadth of material, this is still a fairly slim book, and it's padded out with some odd rhetorical tricks (such as hypothetical conversations between developers that really add very little value to the text). The author avoids too much material that is specific to one platform or programming language, though in general there's a tendency to plump for open source applications (Ant, Nant, Junit, CruiseControl etc). The emphasis is also on functionality, rather than on the details of how to get different applications to work nice with each other.
To finish off the book also includes a useful appendix which helps the reader develop evaluation criteria for choosing the different components of a continuous integration platform.