Customer Reviews

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))

5 star:		(15)
4 star:		(2)
3 star:		(2)
2 star:		(1)
1 star:		(0)

 

 

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.

My first impression was, as the book title suggests, that the book is strictly focused on delivery of software, delivering continuously, to add value to the system and to satisfy the customer (all changes should satisfy the customer and should add value!). That is one crucial aspect for sure. But it is also possible to "deliver continuously" by just throwing changes to production randomly, in bad quality. Thus a systematic process of staging of software is crucial, and introducing (how I call it) "Quality Gates" is essential for releasing software quickly and in best quality.

Continuous Delivery advocates a closer collaboration between all stakeholders that are involved in the software development process. It delivers a holistic approach to software engineering. The book underlines the importance of aspects like Continuous Integration, acceptance testing and component repositories, and discusses many common and valuable best practices. It discusses questions that are relevant for different project phases and stakeholders. The book delivers the authors' views and opinions in a very informative way.

The book does not discuss all possible questions along all development phases (just not possible). It assigns priorities where, in some cases, you may miss another controversal aspect of the discussion (e.g. in the context of "keep absolutely everything in version control"). The pragmatic discussion of "configuration management" will be helpful for many teams, though. In other cases, you may miss another hint or little step. One example for that is in the context of "meaningful commit messages". Here, the potential of task-based development is not really illustrated, maybe because due to the next fact: The book does not (or rarely) show how to implement the strategies with tools. Some sections illustrate tools. Because it is not possible to cover all build tools for all different languages and platforms in one book, such sections give you a nice first impression, though. But for me, these sections are optional for such a book, for a book that is platform/language agnostic. These points are not disadvantages or drawbacks, you should just now them. As always, you should read the Preface first, to understand what this book is, and what it is not. Such a great book cannot cover every single aspect. And there are books like "Agile ALM", which assign other priorities, add other aspects to the discussion and are more targeted to a specific platform/audience (Java/JEE).

Continuous Delivery illustrates an approach that "all code changes are entering a pipeline" to production. I like this nice metaphor for promoting software, staging artifacts from the development team to the final release in production. Some people may claim that this is part of "release management", others may say it is similar to Continuous Integration, and "Continuous Deployment" (deploying versions to production, and to test machines before, continuously). - In my opinion, a change may result in a release *potentially* and *may* start the whole process. And: no changes to the production system without any process; most of the changes will be staged along the full way. The process and the infrastructure must enable the team to promote every single change to production, if you want to do that, however.

Additionally, I think that you should take special care of linking all artifact types to consistent releases, and that you should realize the "pipeline" not as something like a "fire-and-forget" tube. In my opinion, development phases are connected and integrated, and in most cases, it is (hopefully) more an integrated lifecycle, something like a pipline, where both ends of the cube are connected with each other.

Continuous Delivery is a very important contribution. I recommend the book to everyone involved in software engineering.

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.

Improving the software delivery process is something of an interest for me.

There was very little, if any, new content that helped me address this, so I was disappointed in this regards. I've not picked "Continuous Delivery" back up since my 1st read through as much of the content is already online.

If you are new to software delivery, not just slinging code, but the actual delivery from idea to production, then this book will have value for you.

Regardless, "Continuous Delivery" has an excellent message that everyone involved in software delivery should hear.

This book is packed with really great information that spans everything from test data to provisioning hardware environments. The only problem is that there is so much fluff and repetition packed around the useful tidbits that this book takes 80% longer to read than it should. Did anyone actually proof-read this thing before it went to press? The first 3 pages of every chapter are almost the same. If you've got the time or can skim the repetitive parts, there's actually some good content.

It's a good book with a lot of important and practical insights.

The central insight is to examine the cycle time from changing one line of code to deploying a functioning application. If you make it simple and easy to do well, odds are it will be done correctly. If you make it painful to do well, odds are it will break. It's a seemingly simple and obvious point, but it has a lot of powerful follow-on effects.

If you really do turn the dial to 11 on this, every time you check in you create a tested release candidate. The actual deployment is still at the discretion of the organization, of course, but you should have an entire pipeline set up to do load testing, smoke testing, integration testing, unit testing, binary and installer creation, and deployment to a staging area and finally production area. If this process requires manual cranky guru intervention it won't be done often, and the feedback loop to the developers will be slower and less reliable.

One of the best software development books of the year, and a genuine advance in the field.

One of the few occasions when reading and continuously nodding recognizing to all relastic examples in the book that you probably will encounter in real life.

I had two simultaneous impressions when I browsed Continuous Delivery. The first impression was "is there anything really new here?" and the second was "humm... I have actually never seen a book that puts together all these topics that do have an important relationship." Throughout my career I encountered over and over the continuous struggle between diverse teams to successfully develop and deliver software. Communication, coordination, and collaboration have always been an often-ignored important factor that affects the effectiveness of organizations. Add to that the lack of a coherent infrastructure to make design, development, testing, integration, and deployment fit seamlessly and the end result is the nightmares way too many organizations deal with on a daily basis. I decided to read on because I appreciate the importance and complexity of those issues, years ago when I built QA organizations for diverse companies, and the last couple of years coaching and consulting enterprises in the adoption of Lean-Agile practices and the importance of Value Innovation.

Jez and David did a very good job at addressing the infrastructure coherence issues and propose effective ways to bring order. The novel aspect is not the fact that, say, good configuration management, continuous integration, and testing are very important to the increase of software quality, and to both managers and engineers mental health. The value is in the way to make this happen successfully and with minimal effort. They rightfully use the term Delivery Ecosystem and put together innovative thinking with strong bases on the importance to optimize the entire process, increasing quality, reducing technical debt and, best of all, making work life easier to technical stakeholders. The single automated pipeline approach is in agreement with current practices influenced by Lean and Agile.

Part 1 is a very god compendium of practices necessary to every software development organization, which the authors present as the challenges to deliver software. Jezz and David begin by presenting some release antipatterns and what to do about them. Then they address configuration management and continuous integration, where they describe diverse types and practices, pointing out essential characteristics and making suggestions to make them more effective. The last chapter of this part points out the importance of testing and explains it in terms of the test quadrants as proposed by Brian Marick and mention some real life situations.

Part 2 focuses on the deployment pipeline. Jez and David begin with its components--or anatomy--from practices to its stages. They did they right thing by including automated and manual test strategies. The following chapter focuses on scripting for build and deployment by first mentioning some build tools and then guiding the reader by the hand on the basics to get builds and deployments automated; and is complemented by a short chapter on the commit stage wraps it up. The next two chapters focus on testing, automated acceptance and nonfunctional requirements. These topics are not comprehensive due to the extent and complexity of the topics but the authors made a good job at bringing the key factors to motivate the reader to understand their importance and to explore further. This part is concluded with a chapter on deployment; an activity taken way to lightly most of the times and a main point of failure for most organizations. The authors cover zero-downtime releases, emergency fixes, and other.

The last part of the book is on the delivery ecosystem. This is the most important part of the book. I would say that very senior leaders and very senior technical staff with rich, broad and in-depth experience may be able to browse through Parts 1 and 2, but should slow down and read in more detail this part. This is the glue that puts things together.

Concluding. This is a vey good boo that should've been written many years ago to avoid so much waste and pain by so many technical organizations because it puts diverse parts of the software development organization puzzle together in a way they actually fit together. The only aspect I wish was also there, but isn't, is the human factor. That is, how to get not only the complexity of processes and infrastructure to work together coherently, but also how to get the people behind the process and infrastructure to also work together coherently. In any case, that wasn't an objective of this book.

I have never read a book that married all the concepts of the delivery process. This has inspired me to preach and practice this in my organisation. This is a must read for anyone involved in IT.