Rather than define DevOps from a theoretical point of view, I’m writing from what I know and see happens in the teams I work with. In this article, I’m focusing on areas that should help you immediately advance your DevOps knowledge. First, I’ll list and detail what DevOps is and isn’t. Then, I’ll go through my DevOps evaluation to help you assess how “DevOps-y” you and your team are.

What DevOps is At its core, DevOps is a culture of cross-team collaboration and measured improvement in the software delivery process. It started as a shared responsibility model for developers and operators. But now, it often includes security (DevSecOps) and business teams (BizDevOps). In DevOps, a team works together to remove silos, improve collaboration, and create shared ownership over the continuous improvement of the software they build and support.

1. DevOps centers software creation DevOps requires the process of creating software to become as important as the software itself. Rather than exclusively focusing on “new customer-facing features,” the staff should also prioritize improving the system. DevOps-specific metrics highlight problems in those systems, so leadership can see when they need to prioritize “non-feature work.”

2. DevOps is driven by speed (velocity). This velocity allows you to deliver a better product to your customer and continually improve that product through feedback and automation. From product idea to product release, then repeat. This is where the ♾ infinity logo for DevOps comes from — it’s a never-ending cycle of improvement and increasing your release velocity.

3. DevOps implementation is a combination of activities This includes new processes and organizing people in new ways. DevOps expects you to create a new culture and implement new technology to help automate and highlight the important aspects of the application lifecycle. It covers a lot of areas and affects way more than engineers.

4. DevOps is driven by data and metrics A DevOps culture measures its success with these metrics to make educated decisions on what works and what to do next. Four common metrics are Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore Service. These are explained below.

What DevOps is not It’s not a series of checkboxes for “tools to implement.” Implementing Docker won’t make you DevOps any more than Jenkins. Sure, technology can help achieve a higher level of DevOps maturity, but I’ve also seen these DevOps tools misused, making systems difficult to use and fragile to change. Tools must be implemented in a way so that they improve your DevOps metrics.