Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL
Help

Foreword by Martin Fowler

Foreword by Martin Fowler[*]

[*] Martin Fowler is series editor and chief scientist at ThoughtWorks.

In my early days in the software industry, one of the most awkward and tense moments of a software project was integration. Modules that worked individually were put together and the whole usually failed in ways that were infuriatingly difficult to find. Yet in the last few years, integration has largely vanished as a source of pain for projects, diminishing to a nonevent.

The essence of this transformation is the practice of integrating more frequently. At one point a daily build was considered to be an ambitious target. Most projects I talk to now integrate many times a day. Oddly enough, it seems that when you run into a painful activity, a good tip is to do it more often.

One of the interesting things about Continuous Integration is how often people are surprised by the impact that it has. We often find people dismiss it as a marginal benefit, yet it can bring an entirely different feel to a project. There is a much greater sense of visibility because problems are detected faster. Since there is less time between introducing a fault and discovering you have it, the fault is easier to find because you can easily look at what’s changed to help you find the source. Coupled with a determined testing program, this can lead to a drastic reduction in bugs. As a result, developers spend less time debugging and more time adding features, confident they are building on a solid foundation.

Of course, it isn’t enough simply to say that you should integrate more frequently. Behind that simple catch phrase are a bunch of principles and practices that can make Continuous Integration a reality. You can find much of this advice scattered in books and on the Internet (and I’m proud to have helped add to this content myself), but you have to do the digging yourself.

So I’m glad to see that Paul has gathered this information together into a cohesive book, a handbook for those who want to put together this best practice. Like any simple practice, there’s lots of devil in the details. Over the last few years we’ve learned a lot about those details and how to deal with them. This book collects these lessons to provide as solid a foundation for Continuous Integration as Continuous Integration does for software development.

  • Safari Books Online
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint