DevOps is more than CI (Continuous Integration) and CD (Continuous Delivery); it’s about empowering teams to deliver. Building software systems is hard. And although the practice of software engineering has come a long way since the coining of the term “DevOps,” by Patrick Debois over 10 years ago, the cultural underpinnings it endorses to ease the burdens associated with building software systems have not always been well embraced.
Credit: Getty Images
It’s safe to say that we are not there yet. In some respects, the case for DevOps has not been made - not sufficiently well enough for managers who came up with a compartmentalized approach to software development to adopt a new way of thinking, anyway. In other respects, it’s just not a mature space, technologically. And the choose your own adventure argument doesn’t always play well with executive traditionalists.
What is DevOps?
There are many definitions of DevOps floating around, but Gene Kim [The Phoenix Project, Accelerate, The Unicorn Project] probably has the most complete definition.
[DevOps is] The architecture, technical practices, and cultural norms that enable us to… increase our ability to deliver applications and services… quickly and safely, which enables rapid experimentation and innovation, and the fastest delivery of value to our customers… while ensuring world-class security, reliability, and stability… so that we can win in the marketplace.
An easy assumption to make is that DevOps = Automation. Consider this alternative definition of DevOps from Devops: A Software Architect’s Perspective.
[DevOps is] a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality.
Clearly, automation is a significant component in that definition. Specifically, CI (Continuous Integration), which deals with automation that ensures the basic integrity of the code following a commit associated with integrated changes, and CD (Continuous Delivery), which deals with automation that ensures the system is in a working deployable state. But there is a lot more in between and even at the bookends when it comes to DevOps.
What about project inception - the time and effort required to initiate a project and onboard developers? What about the maturity factor of the organization - the efficacy of the tool chain as it relates to the organization’s present capabilities? What about self-service - the technical and organizational support mechanisms that allow software systems to be quickly and iteratively developed as cohesive units?
Better Value, Sooner, Safer, Happier
- John Smart, Deloitte
The benefits of DevOps automation cannot be overstated. However, it’s important to recognize that those benefits are only realized when they support the goals of DevOps, which can be summarized as John Smart so eloquently put it: better value, sooner, safer, happier. That’s not just CI and CD; and it’s not just automation. It’s everything from the culture to the tool chain to the leadership and the technical competencies that enable a holistic systems approach to developing software systems.
The key, then, lies not in better information, but in turning information into information that cannot be ignored.
DevOps is a journey - a journey to empower teams to deliver better software faster, safer and more securely. And like any journey, support is crucial. That support comes from leadership and it comes from technology. The foundations of that support are rooted in evidence. And it’s everyone’s job to ensure that the evidence is information that cannot be ingored.