A sequel to the The Phoenix Project, focusing specifically on DevOps transformation (integrating IT management, software development, and IT operations). You'll learn:
• The challenges faced in traditional IT setups, and how DevOps can help to overcome those challenges to significantly improve the quality, reliability, security, speed and efficiency of IT solutions for both internal and external customers.
• The history, concepts and theories behind DevOps, as well as the 3 core DevOps principles (the “Three Ways”): Principles of Flow, Principles of Feedback, and Principles of Continual Learning and Experimentation.
• The step-by-step process to create your DevOps transformation, including: how to apply the 3 sets of DevOps principles and technical practices in your organization, and integrate QA and InfoSec into each step of your technology value stream.

Book summary at: https://readingraphics.com/book-summary-the-devops-handbook/ ( )

A must read for it, leadership and devs. ( )

If this had been published in the 90s it would've been groundbreaking (and wrong). Published in the early 2000s it would've been bold. Publishing it now is redundant. Terms like CI are so common you don't even need to explain the initialism.

I was severely disappointed with this book. It is NOT a handbook of any kind. This is pure evangelism aimed at managers. Also, very quickly, I realised how extremely narrow the authors' world is. Basically: web services. Almost every argument and anecdote is based on the confines of the crazy world of silicon valley and web startups.

Most of the content is highly repetitive and very broad, not going into any useful details. None of the caveats or drawbacks are considered, just pure hype. It is not nuanced.

The authors are not wrong (most of this is common sense and not some novel process), it's just not a very good book. ( )

DevOps is a movement about the management of computer programmers. It basically says that Development (coding) and Operations (deployment and maintenance) should communicate more and better. Such workability allows for better error detection, swifter deployment of code, etc.

Interestingly, I’ve worked mainly in research environments where I’ve been in charge of both Development and Operations at the same time. I worked in a corporation with separate Dev and Ops for a few years – and I worked on the Ops side then.

I agree wholeheartedly with the insights this book shares. I like rapid, swift, and small deployments over heavy and charged deployments. That allows life to be better on the developers and the operations folk. I prefer to be able to roll-back a small change (that happens several times a day) instead of potentially disabling a system with a large change. That’s how I maintain my code personally, so I have no problem with asking an organization to do the same.

I’m continuing to read about the movement towards a combined DevOps role. Apparently, this group puts out annual reports and has been pushing this out since 2014. It is viewed as a successor to Agile Management of projects. I appreciate their voice and their contribution for the management of computer programmers. ( )

This is an excellent overview of devops, including a summary of lean manufacturing, agile software development practices, security and compliance issues, etc. The authors stayed at a relatively high level - we will not find detailed solutions with exact steps here. Rather, the book points you to areas you might want to research further.

I am familiar with automated testing and continuous delivery practices, so most of the book sounded pretty familiar. The authors focused on IT practices of large and mostly web-based companies, whose business is essentially creating and running software on large-scale server farms. The issues and case studies emphasize large organization issues, changing slow, traditional practices to agile/devops principles.

If your software is used for controlling hardware, however, the book offers little insight. You can’t automatically create CNC machines and hardware components, so creating environments on demand is not possible. It also does not address small and midsize companies.

The text is rather dry and often repetitive. I have listened to the audiobook, if I was reading, I would have probably skimmed quite a bit. Kudos to Ron Butler for bringing life and interest to the text.

Overall this is well worth to keep on your reference book shelf. ( )