DevOps is a fertile area of discussion in blogs, tradeshows and the DevOps Days meetups that Patrick Debois founded in 2009, but he and the other authors of The DevOps Handbook saw a gap in the learning environment: a DevOps guide.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
And so Debois and his cohorts created The DevOps Handbook, a single-reference tome addressing multiple roles and layers of technical competency in one place.
The Phoenix Project, written by Handbook co-author Gene Kim, "gives you a feeling that you get when you find your community," Debois said. The DevOps Handbook continues down that path, from initial spark to DevOps guide. It also opens up the methodology to a wider audience, from early adopters to enterprises.
Debois has held roles in development, systems administration, incident management and related areas such as data center migration. His attraction to DevOps started with the idea that IT professionals shouldn't get buttonholed in roles, with project managers assuming IT knows nothing about development, and IT administrators assuming app owners know nothing about technology.
For modern enterprises, Debois suggested ignoring terminology wars surrounding DevOps, DevSecOps, DevTestOps or even HROps and MarkOps. Instead, he advised, adopt a holistic improvement mindset about an application or infrastructure or team problem.
"Rephrase the question without using DevOps. There's an issue or system underneath," Debois said. Enterprise DevOps isn't about throwing out everything you think you know about running applications. Enterprises don't start fresh; they still run legacy applications and an existing IT estate. DevOps adoption in this context is about improvement.
"Wherever the bottleneck is that hurts you, [that's where] you need to address," Debois said.
For example, as described in Chapter 9, Create the Foundations of Our Deployment Pipeline, of The DevOps Handbook:
"One of the major contributing causes of chaotic, disruptive, and sometimes even catastrophic software releases, is the first time we ever get to see how our application behaves in a production-like environment with realistic load and production data sets is during the release."
In this example described in the DevOps guide, a telecom company experienced adverse effects from inconsistently built applications and environments. Investigation revealed that, because of the long provisioning time required, developers were not given production-like environments for test, resulting in only half of the source code in dev-test matching source code in production. The team addressed the bottleneck by reverse engineering changes into version control and automating the environment creation process. The resulting process shrunk the time to get a correct environment "from eight weeks to one day."
Download Chapter 9, Create the Foundations of Our Deployment Pipeline, here.
Editor's note: This excerpt is from The DevOps Handbook: How To Create World-Class Agility, Reliability, & Security in Technology Organizations, authored by Gene Kim, Jez Humble, Patrick Debois and John Willis, published by IT Revolution Press, Oct. 2016, ISBN 978-1942788003.
See how real DevOps adopters found their path
DevOps is no panacea for IT, dev issues
How does a DevOps team come together?