Continuous Delivery and DevOps: A Quickstart guide

Paul Swartout (2012)
Review date: May 2013
Summary

This is not a big book, and a determined reader will be able to finish it in one evening. It consists of seven chapters. The first chapter lays the foundation by telling a story about a business that was small and successful, then grew, and then became incorporated into a bigger organization and got bogged down by its larger processes. Chapter two is about spotting "the elephant in the room", i.e. determining how the delivery process actually works and why it's flawed. Openness and honesty are emphasized and some techniques that may be helpful at this stage are presented. Chapter three is about the change process itself; communicating the goal, informing stakeholders, and evangelizing. The next chapter lists some tools and core practices, just briefly.

Chapter five is about culture: Openness, transparency, and behaviors that should be encouraged, like abandoning a blame culture. The following chapter is about challenges, both organizational and people-related, such as reaction to change and adoption curves.

The last and final chapter is about measuring. First simple measures like code coverage and commit rate are covered then the discussion moves towards measuring the overall effectiveness of CD.

Opinion

This book presents a very nice overview of how to introduce continuous delivery (CD) into an organization and what a DevOps team actually does. Its primary strength is its broad picture; it doesn't neglect the fact that an introduction of continuous delivery must be preceded and accompanied by lots and lots of information and marketing. The best use of this book is to put in the hands of a technically savvy executive, who would be affected by the changes brought by CD. You could also read it as a gentle introduction to the topic, but in terms of actually implementing anything, this book would probably not get you very far.

As opposed to The Book on CD, it contains very little about tools and technology in general. Actually, I think I found references to two tools in total (Nagios and Graphite). Technical details are not this book's strength. Instead, it should be read as a guide to communicating and managing the changes that an introduction of CD will bring.

I found this book very inspiring, but I would not call it a "Quickstart guide". It's too high level and swishes past concepts that become quite complicated if treated in more detail. For example, the topic of deployment of independent loosely-coupled components gets three quarters of a page, and pretty much nothing is said about branching. Being written the way it is, this book gets away with this approach.

I read it when struggling with organizational issues myself, and found a couple of good angles to things. I get the feeling that the author "has been around" and wants to share some of his "softer" findings, which happened to help me at the time of reading.

My summary and recommendation of this book are as follows: Read this book if you want a map of the entire area of CD and DevOps. The map won't be detailed, but it will cover the entire area. You could also read it as a companion to the more famous book on CD. This is not a "five star", but I really liked that it took on the non-technical perspective, and I always admire authors who can write about a topic in less than 200 pages.

Read it. It's just one evening of your life.

Who should read this book

Those who want an overview of Continuous Delivery or want some inspiration when it comes to introducing CD in the organization will like this book.




News

  • 2014-01-04

    New category! Performance! Reviewed The Every Computer Performance Book. Check it out!
  • 2013-09-10

    Reviewed a book that' slightly less technical, but much more fun to read. It's I.T. Confidential.
  • 2013-08-13

    Reviewed yet another book on Visual Studio 2012 and TFS. I also created a "Microsoft" category and moved the other TFS book there from the "Tools"...
  • 2013-08-05

    Updated the FAQ. Included information about getting a book reviewed.
  • 2013-08-04

    I've reviewed the least technical book on this site yet. It was an anthology = hard to review. See the new section "About technology".