Should we think of DevOps as a methodology?

While DevOps is sometimes referred to as a methodology, it’s better understood as a set of practices, ideas, and methodologies that share a common philosophy: continuous value delivery. Put simply, there’s no one-size-fits-all approach to DevOps—and successful examples of DevOps can look very different from one organization to another.

At GitHub, we design tools for DevOps organizations and work with leading teams and companies. In doing so, we’ve identified a number of common pain points people experience when adopting DevOps.

In this guide, we’ll answer the following questions:

Is DevOps a methodology or a process?
What is the goal of DevOps?
Why are organizations adopting DevOps?
How do you successfully transition to DevOps?
Why are some businesses also adopting DevSecOps?

Is DevOps a methodology or a process?

If you ask 10 people to define DevOps, you’re likely to get at least five different answers. Some people might focus on the practical implementation of DevOps—CI/CD, test automation, and so on—and they’ll call it a process. Others might call DevOps a methodology with a set of processes that work together under a coherent philosophy.

Find out how we define DevOps at GitHub >

But both of these definition miss the larger point: DevOps consists of a set of practices that are adaptable to each business that adopts them.

At GitHub, we believe it’s better to understand DevOps as a framework for thinking about how to deliver value through software. It’s more than a single methodology or collection of processes. It’s fundamentally a set of practices—both cultural and technological. Let’s break that down.

Understanding DevOps as a framework

For decades, people have promoted neatly defined ideas of how each step of the software development lifecycle should work. But what seems like genius in a whitepaper often falls apart in practice because each organization is different.

DevOps acknowledges that. Rather than prescribe every detail, DevOps brings together a set of practices, cultural ideas, and tooling that work under a framework that's malleable for the needs of a given team and organization.

At its core, DevOps seeks to get higher-quality software into the hands of end users as fast as possible. This commitment to continuously delivering value is foundational to any successful DevOps organization—and it’s accomplish in three ways:

Continuous improvement: Small changes are easier to manage and deliver value to users faster than large releases, which can and often do take longer to ship. In a DevOps practice, continuous improvement means shipping iterative changes fast. It also means looking for ways to improve the underlying software with future changes and the SDLC itself to facilitate faster value delivery.
Shared ownership: Everyone working on a product shares accountability for the product and its quality—not just their personal area of expertise. This means that every shares accountability and ownership for the end product they ship to end users.
Automation: Anything that can be automated should be automated across the SDLC in a DevOps practice to deliver value to end users faster through new releases. Automation also helps organizations maximize the time spent building the product, while minimizing the chance for human error.

How DevOps differs from agile and friends

Agile, extreme programming, and other similar development methodologies were reactions to the conflict between traditional programming and software distribution through the web.

Before those ideas became popular, one of the most popular development methodologies was the highly sequential waterfall methodology. In that system, each step had to be complete before the next could start. That often meant lots of paperwork and planning needed to happen before a single line of code could be written.

In 16 months, we've gone from over 30 siloed software engineering groups to a largely cohesive team across McKesson.

VP, Developer Services and Technology Labs Denis Canty at McKesson

The creators of agile software development principles recognized that over-planning stifled the creativity of software developers—and without working code no one could know if the plans even worked. The Agile Manifesto, for example, said that working software was more important than excessive documentation. Being responsive to change was more valuable than sticking to a plan.

In practice, the concepts behind the Agile Manifesto were revolutionary. It recognized that working code was the best way to understand and serve customer needs. But that focus on code also meant it had less to say about the rest of the SDLC.

If agile was a reaction against the old ways, DevOps builds upon agile’s core ideas and applies it to the entire software development life cycle. In fact, some people in the early 2010s called DevOps the second decade of agile.

To understand the difference between DevOps and Agile, it helps to compare their core tenets:

Fail fast vs. continuous improvement: Agile centers on small, fast iterations where failure is embraced because it shows the process is working. In DevOps, the emphasis is on iteration, automation, and deep collaboration across the entire SDLC to improve delivery speeds and software quality.
Developer-centric vs. team-centric: Agile looks at how software developers can best serve customers, but has little to say about how code is tested, deployed, or maintained. In contrast, DevOps brings everyone in the SDLC together under a shared responsibility for delivering value to end users.
Features vs. systems thinking: Agile focuses on the here and now of a particular feature, whereas DevOps looks holistically at software as a system.
Project-centric vs. product-centric: Agile takes a more project-centric approach to software development by breaking large releases into small pieces of executable work. In contrast, DevOps takes a more product-centric view of software and resets the focus from individual projects to holistic products where every decision comes back to how it affects the long-term system as a whole.

What is the goal of DevOps?

The goal of DevOps is to match how we make software with the way the cloud enables us to use it. The cloud took us from an era of barriers—individual servers, software release dates, role-based silos—to an open world where software is ubiquitous.

In the past, software development had distinct stages and a final product that might be compared to a production line. This was understandable—in the era of physical media, software development was a far more regimented and linear process. After all, a final release actually was final in a sense since distributing updates meant restarting the linear production process from scratch.

But the modern SDLC isn’t a production line. Software as a service and other innovations in cloud-based technologies and platforms have made distinct releases as relevant today as punch cards and room-sized calculators.

So, how does DevOps bring the SDLC closer to the always-on, always-up–to-date expectations of the cloud?

Collaboration throughout the SDLC: Rather than thinking in terms of one-off projects, DevOps takes the holistic product-centric view across the SDLC. In practice, that means removing the rigid role-based division of traditional software development and instead prioritizing multidisciplinary teams that take ongoing responsibility for a product’s success. Everyone is accountable for the quality, and other aspects such as security, of that software, regardless of their own particular specialism.
Improved software quality: Each aspect of DevOps is intended to produce better quality software. Automated testing and security checks help prevent issues from ever reaching production. Continuous improvement and practices such as CI/CD ensure bug fixes and other updates get to end users fast. And the architectural choices such as microservices makes it easier to create distributed systems that can respond rapidly to real-time demand, while also minimizing the impact of issues in a particular service.
Faster software releases: DevOps encourages small, iterative changes that are faster to build, easier to code, present a smaller target area for testing, diverge less from production, and have fewer unintended consequences when deployed. This can also impact architectural choices with some organizations opting to leverage microservice architecture to limit the risk of updates to one part of the system.

Why we needed DevOps

There was a time when publishing software meant distributing physical media. Whether it was in a shrink-wrapped box via stores or through a system administrator who’d update each workstation in an office, software releases required advanced planning.

In an era where software development was governed by manufacturing and distribution deadlines, sequential methods like waterfall were a natural fit. But that rigidity came at a cost. Release dates were fixed and missing a deadline could mean losing factory time, trucks sitting empty, and retailers giving shelf space to competitors. Software producers had a choice: they could ship high-quality software slowly at a higher cost or they could sacrifice quality to meet the deadline.

Since adopting GitHub, it's like night and day. It's the collaboration, it's the sharing, it's the community—it's all because of GitHub."

Senior Director of the Build Platform George Swan at Autodesk

The shift to web-based distribution should have freed teams of that dilemma. But many companies and technology teams were organized around fixed release dates with tooling, processes, and team structures to support that software development and delivery model. There was a missed opportunity to improve quality and get value to users faster.

But that wasn’t the only change the web brought. Suddenly, security mattered in a way it rarely had before. Quality was no longer just about catching bugs but also protecting data from any and every bad actor with an internet connection.

Software development had to change. The road that led to DevOps was a reaction to the friction between distributing software through the web and how that software was made.

DevOps provides a framework for software development that fits with the grain of modern cloud applications, meaning practitioners no longer need to sacrifice quality for speed or cost.

Why organizations adopt DevOps

Organizations around the world are adopting DevOps because it helps them ship more reliable software faster. Much of its success is due to its flexibility. Rather than demand radical change, DevOps offers a number of cultural and technological practices that can and should be tailored to the individual circumstances of each organization.

Yet even if the individual implementation changes from one business to another, organizations that successfully adopt DevOps share a number of common benefits. These include:

Collaboration improves quality: Everyone who works in a DevOps environment has a shared stake in the success of a product. An individual’s job is not done when they’ve finished their specific task but when their code is in production—and even then, there’s room to think about how to improve it. That means everyone is continuously collaborating across the SDLC and thinking about how to continuously improve quality and deliver value faster to end users.
Automation reduces uncertainty: DevOps encourages automation wherever possible. This allows people to spend more time focusing on building and improving the software and infrastructure it runs on. It also facilitates a faster delivery pipeline via core practices such as CI/CD, which enable DevOps practitioners to automate the integration and delivery of code changes.
Continuous measurement drives continuous improvement: In a DevOps environment, tools are often used to measure and monitor each stage of the SDLC to provide rapid feedback on system health, real-time demand, and the impact of individual changes. DevOps practitioners use that insight to improve process and make changes based on data.
Improved quality: DevOps practitioners continuously seek to improve the quality of the software they ship. This is partially accomplished through automation, which helps to improve the consistency of testing and security checks. It’s also accomplished through iterative releases and code changes that are easier to build, deliver, and manage while reducing the chance of unforeseen consequences. Collaboration across the SDLC between previously siloed teams such as development and operations is also a key component to improve software quality in a DevOps practice.
Faster release cycles: DevOps helps organizations get value into production faster at a higher quality by prioritizing smaller code changes, which are faster to write, test, and deploy. DevOps also champions the use of automation across the SDLC to create a CI/CD pipeline that shepherds value from planning through coding on to testing and into production.

How your organization can adopt DevOps

Successfully adopting DevOps can require some big changes. But rather than reworking all of your processes and tooling overnight, you can take relatively small steps to get started. This might entail making cultural changes to how often your development team integrates their code or automating small pieces of the SDLC in your organization.

No matter where you are on your DevOps journey, there are six key steps you should take to successfully adopt DevOps:

Change the culture: Success in DevOps starts with deep collaboration between everyone responsible for building, testing, operating, and shipping a product. And that starts with making sure everyone is unified and working together across all stages of the SDLC. This can be a big change for organizations that have role-based siloes between different teams. In a DevOps practice, everyone comes together to deliver higher-quality software faster to customers—and that requires deep collaboration between different people to ensure code is optimized to operate in production environments and production environments are optimized to run the software.
Focus on incremental builds: DevOps favors small changes that can be quickly delivered to customers and that means breaking features into small chunks that are easier to test, minimize the impact of bugs, and can be shipped to production as fast as possible. There are no hard-and-fast rules in DevOps about how many times a day developers should be integrating new code changes—but the most successful DevOps practices integrate and ship multiple code changes a day.
Adopt the right tools: In DevOps, there’s no one-size-fits-all approach to tooling. In fact, “DevOps tools” is a bit of an umbrella term with plenty of products and platforms that fall into this category. Picking the right tools and building the right DevOps toolchain starts with identifying what problems you’re trying to solve and what DevOps capabilities you need to invest in. But there are a number of common areas where you’ll need tooling. Speaking of which …
Automate everything you can: The best DevOps environments think critically about their SDLC and look for places where automation can be applied to remove the need for human intervention—like repetitive tasks such as integrating, testing, and packaging code. By automating repetitive tasks, DevOps helps people make better use of their time and reduces the risk of human error (or people forgetting to run tests, import the right libraries, and so on). As a general rule of thumb, anything that can be automated should be automated in a DevOps practice.

We have a slogan on our team: don't let a human do a machine's job. GitHub helps us achieve that.

Principal Software Engineer Gabriel Kohen at Blue Yonder

Build a CI/CD pipeline: One of the most common examples of DevOps automation, CI/CD applies automation to each step of the SDLC to facilitate a faster delivery of higher-quality software to end users. For example, a developer making a pull request might trigger a series of automated tests to avoid introducing problems into the main branch. And if the pull request is merged, a CI/CD pipeline might leverage automation to initiative the build process of the new software version. Every CI/CD pipeline will look different depending on the needs of the organization in question. But the goal is to apply as much automation as possible to the SDLC to improve software quality and increase the time to deployment.
Measure and adjust: A successful DevOps culture seeks out opportunities for improvement. Monitoring both application and system performance as well as the speed of SDLC is crucial to find inefficient processes. Good metrics help everyone working on a product get a view of their work as part of a larger whole, making it easier to visualize how the changes they make impact elsewhere.

Common challenges organizations experience when adopting DevOps

Before beginning your move to DevOps, you should take note of some of the common challenges that organizations face when making the change. These include:

Tools without the culture: Tooling is often the most visible aspect of DevOps. But tools can have a limited impact without adopting a culture that emphasizes collaboration, shared accountability, and continuous improvement.
Replace old siloes with new siloes: The most successful DevOps environments replace role-based teams with deep, multidisciplinary collaboration. A common misstep is to create a dedicated DevOps team that acts as custodian of DevOps tools, practices, and processes. This approach risks replacing old barriers with new barriers.
Legacy systems resist DevOps models: Integrating older systems and architectures with newer tooling can be costly. The build time for a legacy monolith system, for example, could make it impractical for a CI/CD system where it will be built many times a day.

Adopting DevOps begins with a few small changes, growing until each stage of your SDLC follows the DevOps framework. Even then, there are always opportunities to improve.

The move towards DevSecOps

As a set of practices, DevOps is always evolving—and one of the most apparent evolutions today is through the move to DevSecOps. While DevOps was originally about sharing accountability for how code performs in production, DevSecOps builds on that and seeks to make everyone responsible for that code’s security.

In our connected world, software security is fundamental—and DevSecOps establishes robust processes to build security into every step of the SDLC. Adapting the DevOps idea of continuous improvement, DevSecOps makes improving security an ongoing process and one that begins as early in the SDLC as possible.

DevSecOps pushes security as far to the start of the SDLC––or as far left––as possible. Security begins at the design stage with tools such as static application security testing automatically checking for vulnerabilities before code ever gets to production. Often, that move to consider security early in the SDLC is called shifting left.

Learn more in our guide to DevSecOps, shifting left, and GitOps >

Build your DevOps practice on GitHub

GitHub is an integrated platform that takes companies from idea to planning to building to production, combining a focused developer experience with powerful, fully managed development, automation, and test infrastructure.

Compare pricing plans >

Compare DevOps Solutions >

The availability of out-of-the-box integrations with our existing tooling is a big part of GitHub's appeal. GitHub really helps bring DevOps to life

Agile & DevOps Lead Danilo Suntal at P&G

Go from planning to building	Increase developer velocity
Build roadmap plans right next to your codebase and quickly assign tasks to team members with powerful project boards and tables that are fully integrated into your project. Learn about GitHub Issues >	Reduce the time to commit. Eliminate environment management and context switching for your developers. Simplify IT procurement and maintenance with a secure, managed space in the cloud. Explore Codespaces >

Automate everything	Secure your code as you write it
----------	----------
Automate all your software development workflows with GitHub Actions. Scale reliably and securely with powerful development, test, and automation infrastructure, fully managed by GitHub. Learn more about GitHub Actions >	Secure your code, dependencies, tokens, and sensitive data through the entire software development lifecycle and automatically resolve vulnerabilities. See how we help you stay secure >