Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation [Rilegato]

This book is packed full of great ideas, but it suffers from painful redundancy. In response to another review, an author claims that it was intentional, so that one could skip around without reading from cover to cover. My response to that is that they should have had better editors. I have read many technical books designed for skipping around. None were as tediously repetitive as this one. Eventually, one has to expect that the reader is going to read more than one chapter and might even remember something from a previous chapter and do them the courtesy of not belaboring the main points each time. It's not even limited to once per chapter. The repetition frequently continues within each chapter, section by section.

That said, there are some good gems inside. My favorite parts might be the many real-world stories of how things can go wrong or how applying some of the principles smoothed things out. The detail, diversity and verisimilitude of those anecdotes sets the book apart from many books in the field.

I wish I could say this was a "must have" book, but it's really more of a "must skim" sort of book.

This is one of the most important software books published in years. From the beginning and throughout the book, the authors emphasize the importance in establishing one delivery team consisting of various experts throughout the software lifecycle - developers, DBAs, Systems/Operations, network specialists, testers and so on. The overarching pattern the authors describe is the Deployment Pipeline, which is basically a staged process consisting of all of the steps to go from bare/virtual metal to a working system whenever there is a change to source files. Of course, the only way this can be done is through copious amounts of automation. The other key point the authors make is that this automated delivery system - itself - is versioned with every change. Not just the custom source code, but also the operating system(s), tools, configuration and everything necessary to create a working software system - a crucial aspect of the Deployment Pipeline.

To sum up key points from the book in a few bullets:

* The purpose of Continuous Delivery is to reduce the cycle time between an idea and usable software
* Automate (almost) everything necessary to create usable software
* Version complete software systems (not just source code) for every change committed to version control system
* Employ a Deployment Pipeline in which the entire system is recreated whenever a change is committed to the version-control system and provide continuous feedback
* Identify one delivery team consisting of various delivery experts - build, deploy, provisioning, database, testing, etc. - a concept emphasized in the DevOps movement

The authors go into great detail in describing each of these themes. So, if you want the process of delivering software to any target environment - including production - to be a click of a button and something that can be accomplished as often as the business requires, get this book. When you employ the practices in this book, no longer will you need to artificially throttle changes delivered to users for months or even years because of the expense and risk required to deliver software.

I found the book extremely repetitive, to the point that after the 4th chapter I started skimming through it, as there's no point in reading it all. I don't know if the idea is to repeat phrases until the reader buys into them, or what. I'm quite disappointed that Martin Fowler put his signature on this book. Maybe they're a big happy family at Thoughtworks ... and hey, they need to make money out of Go.

I don't rate this book as just 1 star, as it has some good ideas, but it could have been written in 150 pages (max) rather than 450. Some of the concepts that are repeated until boredom are:
- Don't build the binaries at each stage of the deployment pipeline, create them once an reuse them.
- The capacity testing environment should be as similar as possible to the production environment.
- Script everything!
- Don't let builds that fail unit or acceptance test into production
- Put all the configuration in version control (network, firewall, OS, etc)

I also found the book more directed to manager who don't really know or care about the technology, but want to talk "in techie" language to their engineers. There are too few examples of how to use technology to build a deployment pipeline and most of the talk stays at a very abstract level.

My bottom line, I strongly suggest to read some blog posts and watch some presentations (check infoq) about this subject, it takes less time and it's more enriching than reading this book.