Amazon (hardback, kindle)

InformIT (pdf, epub, mobi)

中文 (in Chinese)
日本語 (in Japanese)
한국말 (in Korean)
português

You can also see a list of all my publications and talks, including slides, on the Publications page.

Continuous Delivery

The book that Dave Farley and I have been working on for nigh on four years, Continuous Delivery, is finally up as a rough cut on Safari. I’m also very proud to announce that it has recently been accepted into Martin Fowler’s Signature Series. The book covers build and deployment automation, continuous integration, test automation, managing infrastructure and environments, configuration management, version control practices, data migration automation, and even governance. That’s a lot of material, and read like this it seems like a bit of a grab-bag of activities that normally gets second billing when you’re delivering software. However these turn out to be absolutely essential activities if you want to get high quality software into the hands of users as fast as possible, and then keep delivering them valuable new features1.

The book has two themes: automation and collaboration. Delivering software of any complexity involves people with a bunch of skills: testers, developers, and sysadmin / operations personnel. The last group of people often gets left out of the process of delivering software until the end, and even testers are often not as heavily involved in the development process as they should be. It’s a pattern we see over and over again when helping people deliver software, and it inevitably leads to unacceptable numbers of defects, poor architectural decisions, and lengthy and unpredictable delays to getting releases out of the door. So one of the main aims of the book is getting everybody involved in the delivery process working together right from the beginning2.

Automation is key to enabling collaboration. If deploying software to testing environments, managing infrastructure, testing, building and releasing your software are manual activities, they are of course terribly error-prone. Worse, delivery teams then typically spend a large proportion of their time fire-fighting to get branches merged and new builds created so that they can be deployed into a production-like environment and tested. This inevitably means that the feedback loop from testing is incredibly slow, and doing things like load testing on staging environments gets left till late in the process, rather than being done from the beginning when problems can be fixed cheaply. Automating as much as possible of the delivery process ensures a much tighter feedback loop, and frees people to focus on high-value activities like evolving an appropriate architecture, exploratory testing, and making deployments and releases low-risk, push-button processes.

There is also an organizing principle for all of these activities: the deployment pipeline3. The description and elaboration of this pattern forms the core of the book. The idea behind the deployment pipeline is to model the part of your project’s value stream that goes from check-in to release, and then to automate it. Every check-in triggers a new build, which then passes through the deployment pipeline as shown below (inspired by Chris Read).

Deployment Pipeline Sequence Diagram (thanks to Chris Read)

The deployment pipeline allows everybody involved in delivering software to get fast feedback on the status of every change that is introduced to an application. It makes it simple to trace which builds have been through which environments, what the results were, and what’s currently in each environment. Finally, it allows testers and operations people to self-service the build of their choice into the environment they control. The upshot is faster feedback, better collaboration within delivery teams, and – because each process from check-in to release is automated – fewer errors, more reliable releases, and shorter cycle times.

The book is still in Rough Cuts, which means we’re actively seeking out feedback to help us improve it. Please let us know what you think: the book has a feedback section, and we’ve created a group to discuss the issues we cover in the book. We’ll be posting outtakes, code examples, and further material from the book here, as well as providing regular updates on the state of the art in this space. We look forward to seeing you here!


1 We got the idea for the book’s name from the first of the Twelve Principles behind the Agile Manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”.

2 There’s a whole movement devoted to increasing collaboration between developers and operations types.

3 Dave, along with Mark Rickmeier, came up with the idea of deployment pipelines back in 2004. The idea then circulated within ThoughtWorks for some time, and was first documented publicly in 2005 (in a blog entry by our colleague Sam Newman). Dave and I have both written papers on the subject. More recently, there has been a new variation on the theme in the shape of continuous deployment.

  • Aaron

    The link to the book is broken?

  • jez

    Thanks Aaron – it should be fine now. The correct URL is http://my.safaribooksonline.com/9780321670250

  • Pingback: Most Tweeted Articles by Agile Development Experts

  • Pingback: The week in links « turnings

  • http://www.javamonamour.org Pierluigi Vernetto

    Hey Jez, I am progressing with your book and it’s really a gold mine of precious advice. I have corrected my post on http://www.javamonamour.org . You guys rock!
    I would suggest also selling a podcast of the book that one can listen on IPod…
    pierre

  • Marco

    Your book is my new bible! Excellent work, congratulations!
    Just my pregnant wife was slightly worried when she saw the title ;-).

    Ah, and I just stumbled on a typo on page 151: should be Gant instead of Gantt (just in case you plan to release a second edition – hint hint wink wink nudge nudge).
    Marco

  • Adam Flynn

    I’ve just finished reading your book and was very impressed with the thoroughness with which you treat the subject.

    Out of curiousity, does this book essentially replace “Continuous Integration: Improving Software Quality and Reducing Risk,” also in the Martin Fowler Signature Series? I have yet to read that one so I’m wondering if it has much additional information or is now mostly superseded by “Continuous Delivery.”

  • jez

    Thanks Adam.

    I certainly wouldn’t say we replaced the continuous integration book. That book is very well respected, and has more detail about CI, including more examples, explanation and advice, than we could include in the much shorter space we had. This makes it particularly useful for less experienced practitioners. But if you’re 100% comfortable with implementing the content of the CD book, I’m not sure the CI book would add tons of value.

    Jez.

  • Pingback: Thoughts on Application Lifecycle Management (ALM) « Early and Often

  • Pingback: OCTO talks ! » Le déploiement continu par Thoughtworks : Go!

  • http://www.if4it.com Information Technology

    Hello,

    I just wanted to say that I appreciate the material you’re publishing and all of the hard work that goes into it.

    The premise of “continuous” and “automation” go hand in hand and represent a series of best practices that seem to have been lost during the Dot.Com boom, when the industry would hire anyone and everyone that could fog a mirror, say the word “technology,” and spell “HTML”.

    My only recommendation is that you clearly specify and stress that the movement of code from any one environment to another is a Release (and therefore the practice of it), in and of itself. For example:

    * Release to Common Build Environment
    * Release to Integration Testing Environment
    * Release to User Acceptance Testing Environment
    * Release to Education Environment
    * Release to Production Environment
    * Release to Disaster Recovery Environment
    * Etc.

    I’m glad to see that you’re taking the time to push solid best practices and I wish you continued success in these endeavors. They can only help the industry.

    My Best,

    Frank Guerino
    Chairman
    The International Foundation for Information Technology (IF4IT)

  • saleem

    another typo: page 94, “..the basic behavior of you[r] system..”

  • Saleem

    couple more typos (sorry, i seem to have an eye for this stuff): page 394, you use DCVS a couple of times instead of DVCS.

  • Saleem

    sigh.. it really is a very well written book, i just can’t help but point out the occasional typo in case you’ve got another edition coming out. page 351: “develop the new implementation alongside the [old] one.”

    plus another DCVS on page 398.

    my apologies for using your blog comments for this, just couldn’t find another way to get in touch.

  • jez

    @Frank

    Thanks very much for your feedback and your appreciation.

    I hope the problem you mention is one of terminology rather than emphasis, because I certainly agree with you. In retrospect we certainly could have made our choice of terminology clearer. Throughout the book, we’ve used the term “deployment” to mean what you call “release”. In the book, “release” is used to mean “release to users” which, if you manage your own production environment (as opposed to shipping CDs or hardware devices, say) is also “release to production environment”.

    We do emphasize, in chapter 5, that one of the core principles of the deployment pipeline is “deploy the same way to every environment”. We expand on this throughout chapter 10, where in the first paragraph we state that “When deployment to production occurs, the same process should be followed as for any other deployment.”

    Having said that, it’s probably impossible to overstate this point.

  • jez

    @Saleem – thanks for the feedback on the typos. If you find any more, please email them to me on jez at thoughtworks dot com.

  • Michael

    I am wondering…does Continuous Delivery and Continuous Integration fall under Configuration Management, or under Software Engineering?

    I ask this, because I am not an “experienced” developer, however I do have experience in automating builds, setting up automated deployments, including Unit Tests Suites within our build process, Creating JavaDocs, Including Coverage Reports, and Creating scripts to automatically deploy (the same EAR file) to each of our environments, only including new configuration files to our deployment process.

    Many people would say that this is configuration management, however I would argue that this is software engineering, not including development as a subsystem/process of software engineering.

    I also have read the majority of this book. It is awesome. How would one market themselves, if they are well versed and has experience with the efforts detailed in this book, given that many wouldn’t consider this work software engineering?

  • Pingback: OCTO talks ! » Le Cloud au service de l’intégration continue

  • http://buildyourownsoftware.com/category/uncategorized/ build your own software

    I do trust all of the concepts you’ve introduced on your post. They’re very convincing and will certainly work. Nonetheless, the posts are too short for novices. Could you please lengthen them a little from subsequent time? Thank you for the post.

  • Chris

    Is there another way of getting a preview copy of your book other than through a subscription on Safari ????

    • http://continuousdelivery.com/ Jez Humble

      Hi Chris. Since the book was published in August 2010, it’s no longer available as a preview. You can buy it using the links on the top left of the website (“Get the book”)