By now, most people in technology are familiar with the term DevOps. What we call “DevOps” will often differ between organizations, yet one thing remains the same: DevOps is defined by people building software and how they work together, not simply by what’s in their toolchain.

As part of GitHub’s Professional Services team, I’ve had the opportunity to see the way many companies have adopted DevOps and what it looks like for teams in their day-to-day work. Here’s what we’ve learned—and some common DevOps misconceptions we’ve encountered along the way.

What is DevOps?

DevOps has been defined in many ways: a set of practices that automate and integrate processes so teams can build, test, and release software faster and more reliably; a combination of culture and tools that enable organizations to ship software at a higher velocity; a culture, a movement, or a philosophy. None of these are wrong, and they are all important aspects of DevOps—but they don’t quite fully capture what’s at the heart of DevOps: the essential human element between Dev and Ops teams, when collaboration bridges the gap that allows teams to ship better software, faster.

For organizations, DevOps provides value by increasing software quality and stability, and shortening lead times to production. For developers, DevOps focuses on both automation and culture—it’s about how the work is done. But most importantly, DevOps is about enabling people to collaborate across roles to deliver value to end users quickly, safely, and reliably. Altogether, it’s a combination of focus, means, and expected results.

• The focus of DevOps is people.
• The means of implementing DevOps is process and tooling.
• The result of DevOps is a better product, delivered faster and more reliably.

Common DevOps myths

Once we understand what DevOps is, it’s easier to identify what it isn’t—let’s look at a few misconceptions you may have heard before.

Myth: Having DevOps tools equals doing DevOps

Sometimes we hear teams say, “We use [tool X] or automate [X process], so now we’re doing DevOps!” But as noted above, tooling and automation are part of how you implement DevOps (the means), not DevOps itself. It’s a collaborative human endeavor, and our tooling—and the automation it supports—is how we get this work done. There are many tools in this space; while it’s tempting to immediately adopt a specific set of DevOps tools or a prescribed toolchain to try to shortcut your DevOps journey, choosing the right tooling for your organization is key to your success.

Myth: DevOps is Agile development

One of the most common myths we hear is that Agile and DevOps are the same. While it’s easy to confuse the two, processes like Agile are part of how to DevOps, not what DevOps is. Agile, Lean, Extreme Programming, and other “work fast, ship often” models are just a few of the many ways teams can make DevOps successful. Agile ships software faster, but it doesn’t ensure collaboration with other teams in the software lifecycle, and can overwhelm test, QA, and operations teams if they’re in a siloed organization.

Myth: There’s only one “right” version of DevOps

In practice, DevOps is different for every organization, as each brings its own unique constraints, strengths, talent, and goals; the tools and processes that worked in one company won’t necessarily translate into success for another. Although there are common practices and principles for successful DevOps transformations, it’s not pre-packaged in a box, and there are many ways that companies can successfully implement their own.

Myth: DevOps is only about delivering value

While it’s true that DevOps delivers value for organizations, helping them develop and deliver innovation to their end users with speed, stability, and reliability, there’s so much more to it. DevOps started, in part, as a way to make software more humane. By automating our workflows, people can focus more on the task at hand. This brings more joy to our work and decreases burnout.

Common DevOps principles

There are a few key concepts and principles that every successful DevOps program shares. Combining these with the right tooling, process, and culture will help teams find DevOps success. While DevOps will look different for each organization and team, here are a few starting pointers:

• Shared ownership: Effective collaboration relies on shared ownership—understanding and embracing that everyone is responsible and contributes to the work in some way. Each person involved, whether building the application, maintaining it, or contributing in another capacity, knows that they have a stake in the outcome. The old process of tossing work over the wall at the other team is broken down in the DevOps paradigm.
• Workflow automation: Automation enables consistency, reliability, and efficiency, making it easier to troubleshoot problems and bugs. By leveraging automation, we can help avoid the trap of institutional knowledge, where only certain people know how to do certain things.
• Rapid feedback: Automating repetitive tasks like reporting and testing provides rapid feedback so teams can quickly understand the impact of their changes throughout the software lifecycle. That understanding helps teams work together more efficiently, as passing changes from coders to builders, builders to testers, and testers back to coders creates a long loop of dependencies and blockers. Rapid feedback allows the developers and operations teams to make decisions together, and implement changes based on shared data.

Organizing your team for DevOps

DevOps programs are built on shared principles, and organizations will implement DevOps in different ways.
There isn’t one “perfect way” of approaching DevOps that’s better than another, but there are tendencies and common pitfalls that can make particular approaches more challenging than others.

• Dedicated DevOps team for the company. DevOps tools are numerous, complex, and often require specialized knowledge. By dedicating a specific team to bridging the gap between development and operations, you have a team that specializes in these tools and processes. A challenge with this approach is that it creates yet another silo, and is a bottleneck for approvals. Rather than breaking down the barriers between development teams and operations teams, DevOps teams themselves become the broker. If the DevOps team is small, they can end up being a blocker as numerous teams attempt to onboard and contribute to the established processes.
• Dedicated DevOps engineers on each team. Assigning a DevOps engineer to each development team is another approach that can be successful. Having a DevOps engineer who spans development and operations teams for a given feature or product has the benefit of having a dedicated expert for certain tasks. Ideally, this expert can then guide and support the rest of the team on using tools and best practices. But this approach also risks treating this role as a funnel for automation work, sometimes even turning DevOps engineers into the lone gatekeeper for deploying code to production. Without carefully watching team practices, this can become overwhelming and lead to burnout for DevOps engineers, leaving the rest of the team unable to fill their shoes.
• One team for Dev and Ops. A third approach we see is having one team for specific subsets of features for a larger application, in which each member is responsible for both development and operation. In these teams, deployment and promotion through environments like testing, staging, and production are integral parts of the development process itself. This approach helps avoid the pitfalls of the other two, but has the added challenge of a steeper learning curve. When this approach is done well, we often see specialists within the team taking on various responsibilities. The team shares the overall responsibilities, but individuals can support the rest of the team by picking up different pieces that match their interests or background.

There’s no single path to DevOps

DevOps starts with your people, then is put into practice by building with your team’s culture, goals, strengths, and constraints in mind. Understanding these will drive how you design your specific processes, guide how you choose your DevOps tools, and shape which DevOps best practices you adopt—all leading your organization to its own definition of success.

There’s no one “right” way to implement DevOps. And like everything else in technology—and anything involving humans—DevOps tooling and practices will change. By standardizing and automating your infrastructure, application delivery, and policies as code, you’ll be ready to adapt quickly—helping your team do their best work faster, while staying competitive.

Looking for more on DevOps? Check out the DevOps with GitHub Actions course on GitHub Learning Lab or our roundup of DevOps resources.