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.