Continuous Delivery from Jezz Humble and David Farley is an important contribution to the field of software development. It takes continuous integration to the logical conclusion and covers how to set up a continuous integration system which covers everything from check-in to delivery to production. It doesn't state you have to deliver directly in production, but it will explain how technically it is achievable to do that and what enormous benefits this brings to your organization.

Continuous delivery consists of three parts: 1) Foundation, 2) Deployment Pipeline, and 3) Delivery Ecosystem

The first four chapters cover the fundamentals the rest of the book is based on. The first chapter provides some problems with more traditional approaches and also introduces some principles extracted out of continuous delivery. The next three chapters cover topics that provide the basics of continuous delivery. Someone involved with agile development for a while is probably aware of most of this and it will be a quick read. For new people, these chapter provide a quick introduction to these topics so that you can understand the rest of the book. The chapters are: "configuration management," "continuous integration," and "implementing a testing strategy."

The second part is the core of the book. It explains the continuous delivery pipeline. This pipeline is a series of stages (a series of continuous integration systems) each stage covering higher-level wider-range of testing so that the confidence in the product increases the later the stage in the deployment pipeline passes. The stages the authors recommend in the deployment pipeline are: commit, acceptance, capacity, manual, production. Each of these stages (except for manual) has its own chapter which explains tools and practices that the authors have found useful in that stage of the deployment pipeline. The part also contains an additional 'foundation' chapter about build and deployment scripting.

The last part of the book is one that I myself found most interesting which covers perhaps some 'advanced' topics. The part is called "delivery ecosystem" and the chapters aren't directly related to each other but each chapter covers a common topic related to the deployment pipeline. Chapter 11 talks about managing and automating your infrastructure as part of your build also. It introduces a vast amount of topics related to automation (pupper, chef), virtualization, cloud computing and monitoring. Unfortunately, the book is only able to touch a little upon each of these topics as each of them could easily fill several others books (and they do!). Chapter 12 covers a very frequent problem in testing and test automation related to managing data. It explains several different approaches and then evaluates them and shares the experiences and recommendations of the authors. Managing test data is a common problem and is rarely covered in the amount of detail as this book does. Chapter 13 discusses different scaling options by componentizing the product and what effect this has on the continuous deployment pipeline (basically adding another dimension to the pipeline). Chapter 14 is about version control and can be summarized as "avoid branching" but the authors do a good job explaining that message and why the alternatives are indeed worst. Chapter 15 was a short (and I slightly disliked this chapter) about managing continuous delivery. It felt like the standard "and now... what actions to take"-chapter. It was a bit shallow though.

When the book was published, I read it through rather quickly and liked it but didn't appreciated the depth of the book yet. I re-read it the second time more thoroughly and enjoyed the careful comparisons and explanations of the recommendations of the authors. They shared the experiences they have had very clear. The book is interesting to me as it covers a vast area and thus it is hard to not touch everything shallowly, but they don't, they go in more depth at the points where the authors feel it is appropriate (for example, parts that are controversial or often done differently).

The book isn't perfect though! As some other reviewers pointed out, it is repetitive and should have been thinner. I agree with that. Also, sometimes the book side-tracks in interesting facts that are unlikely to help the reader a lot such as the history of version control. Next, the book contains some very basic things that could have perhaps been left out (or put as appendix), such as an explanation of maven. My last comment is that the book sometimes contradicts itself such as the recommendation to do things "at the beginning of the project" but then later stating that "at the beginning of the project, all these decisions will change". There I still felt the influence of standard 'project' thinking.

With all these drawbacks, I still decided to rate the book five stars because I do think it is an very influential and important book. It tells and *shows* that continuous delivery is not just a perfection state but that it can be achieved today. Not only that, it can be achieved in larger projects, not just small web projects. This is a huge contribution to the industry and I think and hope that the practices of continuous delivery will become standard practices everywhere. Excellent read (except for the repetition) and highly recommended.

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.

This was a good read. The authors teach a good amount of principles to adhere to when creating your CI/CD pipeline(s).

As mentioned by others, the book is a bit repetitive and could have been condensed a bit without diminishing the value from what was taught. There were also some parts that I felt were outdated, but the book is over 10 years old so that would explain it.

Nonetheless, I recommend picking it up for a read to get some good nuggets of practical knowledge on CI/CD. There are still some principles taught that I believe hold value to this day.

Technologists operate in a fast-moving environment. Languages rise and fall. Application strategies constantly shift across new hardware. Presentation layers move between thick and thin client across desktop, laptop, tablet, and phone architectures. For that reason, technology writers produce materials that have a relatively short shelf life.

Every now and then, books are published which make a lasting contribution to the field of computer science and software delivery (i.e. Knuth's Art of Computer Programming or Brooks' Mythical Man Month) and find interested readers regularly pulling them off their shelves. Continuous Delivery by Farley and Humble is one such book.

Combining an uncanny vision for emerging technology trends, awareness of available delivery tools, massive experience in the realm of software delivery, and well articulated delivery strategies, the authors offer a relatively vendor-agnostic discussion of the delivery pipeline that ensures code quality, quick time-to-market, and painless release processes.

This book is highly relevant for anyone involved in the field of technology: developers, testers, project managers, scrum masters and product owners, as well as CTO's / CIO's.

Those involved in software development should be familiar with agile development methodologies and the additional activities that are integral to realizing the benefits of iterative development, like automated testing, continuous integration, and pipeline automation. Taken together, these components constitute continuous delivery.

The goal is push button deployment. Once someone checks in code, press a button, and the code gets compiled and tested, configurations are set, data is migrated, environments are readied, and code is released to production. The benefits stem largely from the drastically shorter time from concept to release as well as increased reliability.

The authors demonstrate how to achieve continuous delivery whether you work at a start-up or an organization with a large embedded code base with more traditional development and operations practices. Yes, incremental improvement is possible, and not all organization achieve complete automation. The book is very comprehensive, getting down to the code level in some instances. When impractical to go deeper on certain topics, addition materials are referenced.

This is recommended reading material for anyone contemplating a move to continuous delivery and/or anyone seeking to understand its components better. It will surprise and make believers of the old-timers that are steeped in waterfall development methodologies.

--Nick McCormick, Author, "Acting Up Brings Everyone Down"

Of course, there are few other books in the market that touch on Continuous Delivery. However, here in this book the authors Jez Humble and David Farley have provided detailed and in-depth treatment of this subject with real examples that are relevant. I have been in software development and delivery business for many years, and I do not hesitate to say that I have experienced all of the anti-patterns described in "some common release antipatterns" not once but several times. If I have to choose the parts of this book, my favorites are Chapters 2. Configuration Management, 3. Continuous Integration, 8. Automated Acceptance Testing, 10. Deploying and Releasing Applications, and 15. Managing Continuous Delivery. Believe me, I have read and reread these chapters. I recommend this book to anyone who wants to be successful using the Continuous Delivery practice in an Agile environment. Even if someone is already working in an Agile environment and practicing Continuous Delivery, I am sure there are best practices that they can pick up from this book and use right away.

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.

A huge mistake was made by the authors of this book, in underestimating their work insofar as believing that it would be used mostly as a reference rather than read from start to finish. It's a book which offers insight, based on experience, rather than being a hands-on lab reference. But perhaps it should have been called "Continuous Duplication"? What's most annoying is that once you get started you soon realise that you HAVE to read the entire book, despite the repetition. There are loads of hidden gems. To be sure, you'll only need to read it once! However, the underlying content is excellent, relevant and, one senses, written by two highly experienced experts in this field. I give it 7 stars, less 3 for repetition which makes 4. LOL ... I probably will read some parts again!

Every serious software engineer ought to read and live by this book. I have employed the outline presented here in multiple professional projects and they have greatly benefited my team each time.

Rarely have I seen a book so full of teachings and so uniformly dense with knowledge. I have enjoyed it end-to-end and am here back for writing a review after quite a wile. The book will be accessible for business management people as well, and will give insight on the "why" as well as the how.

I mostly recommend it for teams of developers that are a bit cranky and stuck in their old ways.

The kind of book you buy multiple copies of, just to make friends or co-workers happy one day.

I would have appreciated it even as Christmas present !

This book is a must read gor people who want to learn about CI CD CT and DEVOPS.

It also enumerates how CD can calibre with agile software development practices. Highly recommended.

I read this book from cover to cover and I have to say, it is a must-read book for any IT professional. It contains some invaluable tips about branching, tests, environments, how to start a project, and so on. The authors seem to have great experience in several types of projects, and they share their experience in this book. You can learn from their experiences and try to put into practice some of their advice.

I know it is hard for a single SWE to change things in a corporation, but some of the good practices discussed in this book can be applied to small teams. Moreover, the book contains some good advice about how to avoid (and identify) the most common anti-patterns or bad behavior.

As a negative point, the authors discussed some technologies in this book, but obviously, these technologies nowadays are totally obsolete. It can be fixed, of course, in a new release, but it doesn't harm the overall benefits.

Questo libro è considerato una pietra miliare del movimento DevOps.

Ed in effetti sono d'accordo sul fatto che sia il miglior libro sulle pratiche DevOps di sempre. Nelle sue pagine illustra le migliori pratiche e quali problemi risolvono.

Il libro è anche una cassetta degli attrezzi di tutto ciò che va sapito sulla CI, dall'automazione della distribuzione alla gestione della configurazione alla gestione dei dati e persino ad aspetti di qualità e controllo.

Forse poteva essere compattato in il libro meno dispersivo.