The DevOps Handbook, 2nd Edition: How to Create World-Class Agility, Reliability, & Security in Technology Organizations 2nd Edition

This book is a worthy sequel to The Phoenix Project, a kind of novel that illustrated the principles of DevOps in a similar fashion that Goldratt's The Goal explained a generation ago the principles behind lean manufacturing and the theory of constraints. It used a fictional story to help the reader understand the "why" of DevOps and what a successful end state looks like. In The DevOps Handbook the same set of authors continue where they left off, this time explaining the "how" of DevOps, how the three Ways (flow, feedback, continuous learning) are implemented in practice. This book lets you see through the current hype around DevOps, much of it coming from tool vendors positioning their various "solutions" as silver bullet, putting the technology in its rightful place beside people and process. While in the Flow section there is plenty on continuous integration and continuous delivery (CI/CD) that for most people is what first comes to mind when they think of DevOps, since so much has been written about this elsewhere I don't think this is the most useful part of the book. To me the most valuable section, because it's not covered so well elsewhere, is the one on the principles of feedback, how information flows back from production environments to development via telemetry and A/B testing. But perhaps what is most useful and by itself makes this book more than worth its price are the various case studies from the companies with the most mature DevOps practices, what problems they were struggling with at first and how they got to where they are now. The book ends on a great note with the appendix, which elaborates on the lean principles on which the theoretical framework behind DevOps is built, a how to guide on "blameless postmortems", and an extensive list of references, most of them with URLs, so that the reader can drill down on all the subjects covered.

he DevOps Handbook" is an exceptional resource! It provides invaluable insights into the world of DevOps and is a must-read for anyone involved in software development and IT operations. The book is well-structured, filled with practical guidance, and backed by real-world examples. It has been instrumental in helping me understand and implement DevOps principles and practices within my organization. Highly recommended for anyone looking to improve their software delivery and IT operations processes!

I read the Phoenix project and then followed it up with this book. There are a number of good sections for leaders to reference in their journey to Devops. The case studies were also interesting to hear, even one from my own company.

This is an engaging, and well written book all the way through. Excellent, practical application and explanation of Devops principals. The mention of numerous products along the way really helped me discover new tools. A serious blueprint for any technology organization.

Full Detail as described, ready to go implement best practices after reading.

DevOps has become a meaningless buzzword, but it used to actually mean something. I've been a software engineer for two decades, but only recently have I really started thinking about why some organizations are highly productive and others are hopeless. Teams I've been on, and I personally have literally been ten times as productive at some places than at others. Why? What's different? After reading this book and comparing its examples and counterexamples to different orgs I've been part of over the years I have to say I strongly agree with about 90% of it, and I don't disagree with any of it.Anybody whose work is even remotely related to software development should read this book. It's not overly technical, so you don't have to be neck deep in code on a daily basis to understand the points it makes. It's about how to (and how not to) structure teams and the org as a whole to maximize the actual business value being created. Devs, product owners, QA people, managers, C-suite types, anybody whose responsibilities even remotely relate to software development really need to understand the concepts that this book presents. I'm honestly annoyed with myself for not having read it sooner.

As an SRE trainee, the book helps me a lot to learn and deepen in several concepts that I want to apply in my current position. Highly recommend, I would even say mandatory to read it.

we did a lot of this (other than avoiding blame) at HP 10 years ago, but the new lingo was useful. Great real-world examples. Don't try to read more than 25 percent of the total pages a day. Let it soak in. I will say that a third of the book was citations, inflating the kindle length. The authors also need to add explanations of the critical chart that we write for a project before conversion. %C/A won't search on a kindle. You end up with California references. I never did learn what VA meant. For being the top three requirements for using this approach, it felt rather like a note that ends "whatever you do, don't---"I would also like more on ‘Kolmogorov-Smirnov’ .