What Is DevOps? A Plain-English Explainer

DevOps is a set of practices and a team culture that combines software development ("Dev") and IT operations ("Ops") so that code can be built, tested, and released faster and more reliably. It isn't a single tool, a job title, or a product you buy — according to AWS's own definition, DevOps "increases an organization's ability to deliver applications and services at high velocity," by having development and operations teams work as one group instead of handing work back and forth between silos.

What is DevOps?

DevOps describes an approach where the people who write software and the people who run it in production work together continuously, instead of development finishing a project and "throwing it over the wall" to a separate operations team. Researchers Len Bass, Ingo Weber, and Liming Zhu define it more formally as a set of practices meant to reduce the time between committing a code change and that change safely running in production, while keeping quality high.

In AWS's framing, DevOps is a combination of three things working together: culture (shared ownership and responsibility between teams), practices (the specific technical habits like CI/CD and automation), and tools (the software that makes those practices possible). None of the three alone is "DevOps" — a team that buys a CI/CD tool but keeps development and operations in separate silos hasn't adopted DevOps; it's just automated its old process.

DevOps the practice vs. "DevOps Engineer" the job title

This is one of the most common points of confusion. DevOps, as originally conceived, is a way of working that an entire team adopts — not a single person's job. In practice, though, many companies have created "DevOps Engineer" as a job title for someone who builds and maintains the automation, pipelines, and infrastructure that make DevOps practices possible: CI/CD pipelines, deployment scripts, monitoring dashboards, and cloud infrastructure. Critics of the title argue it reintroduces the specialist silo that DevOps was meant to eliminate; defenders argue that someone still has to own the tooling, even on a highly collaborative team. Either way, when you see "DevOps Engineer" in a job listing, it almost always means: infrastructure, automation, and CI/CD pipeline work, done within a team that's trying to practice DevOps culture broadly.

The core practices

Based on AWS's and GitHub's own documentation, DevOps is generally built on these recurring practices:

• Continuous integration (CI): Developers merge code changes into a shared repository frequently — often multiple times a day — where automated builds and tests run immediately. GitHub's own documentation describes this as surfacing errors sooner and making it easier to merge changes from multiple developers, since each commit can trigger a workflow that builds the code and runs linters, security checks, and test suites automatically.
• Continuous delivery / continuous deployment (CD): Code that passes CI is automatically built, tested, and staged so that a deployable version is always ready — continuous deployment goes a step further and pushes that build straight to production without a manual approval step.
• Infrastructure as code (IaC): Servers, networks, and cloud resources are defined and provisioned through code and version control (tools like Terraform or AWS CloudFormation) instead of being configured by hand, so environments are reproducible and changes are tracked like any other code change.
• Configuration management: Automating how operating systems and servers are set up, so the same configuration can be applied consistently across many machines.
• Monitoring and logging: Collecting metrics and logs from running systems, with alerts that let teams catch and respond to problems quickly — treated by AWS as essential to closing the feedback loop between "Ops" observing production and "Dev" fixing issues.
• Microservices: Many DevOps-practicing teams structure applications as small, independently deployable services rather than one large monolith, so individual pieces can be updated and released without redeploying everything.
• Frequent, small releases: Shipping smaller changes more often is less risky and easier to debug than infrequent, large releases — if something breaks, it's easier to pinpoint which small change caused it.

Why organizations adopt it

AWS lists the practical payoffs of DevOps adoption as: speed (teams can innovate and adapt to market changes faster), rapid delivery (more frequent releases mean customer feedback gets incorporated sooner), reliability (automated testing and monitoring catch problems before they reach users, even as release frequency goes up), scale (automation and consistent, code-defined infrastructure make it easier to manage systems as they grow more complex), improved collaboration (shared ownership between development and operations reduces the handoffs and miscommunication that slow traditional releases down), and security (automated compliance and configuration checks let teams move fast without skipping governance). None of these benefits come automatically from installing a tool — they come from combining the tooling with the underlying culture change AWS describes as central to DevOps.

The DevOps lifecycle

Most descriptions of DevOps organize its practices into a repeating cycle, often illustrated as an infinite loop, covering these stages:

1. Plan — defining the work, from feature requests to bug fixes, usually tracked in a project-management or issue-tracking tool.
2. Code — writing and reviewing the actual software changes, typically in a shared Git repository.
3. Build — compiling or packaging the code into a deployable artifact, often as part of a CI pipeline.
4. Test — running automated tests (unit, integration, security) against the build before it goes further.
5. Release — preparing a tested build for deployment, sometimes with a manual approval gate (continuous delivery) and sometimes without one (continuous deployment).
6. Deploy — pushing the release into a production environment, frequently using infrastructure-as-code tooling to provision whatever it needs to run on.
7. Operate — keeping the running system available and performant, which is where traditional "Ops" work concentrates.
8. Monitor — collecting metrics, logs, and alerts from the live system, feeding problems and usage data back into the next planning cycle.

The loop is deliberately circular: insights from monitoring a live system directly inform what gets planned next, which is the structural difference from older, strictly linear development processes where operations only got involved after development had already finished its work.

Related terms you'll run into: DevSecOps and GitOps

Two practices frequently mentioned alongside DevOps:

• DevSecOps bakes security checks directly into the DevOps pipeline — static analysis, dependency scanning, and dynamic testing run automatically as part of CI, rather than security review happening only at the end, right before release (often called "shifting left").
• GitOps treats a Git repository as the single source of truth for a system's desired state — deployment configuration lives in version control, changes go through the same code-review process as application code, and rolling back is as simple as reverting a Git commit.

DevOps vs. SRE vs. platform engineering

These three terms overlap heavily and are often used loosely, but they come from different origins:

Google's SRE team predates the DevOps movement, and some of SRE's original authors describe it as one concrete implementation of DevOps principles, with specific engineering practices (like error budgets) layered on top of the general philosophy. Platform engineering, meanwhile, has grown as a response to DevOps at scale: rather than every product team building and maintaining its own CI/CD pipelines and cloud infrastructure from scratch, a dedicated platform team builds shared, self-service tooling that other teams consume — similar to what our GitHub Actions and CI/CD explainer covers at the pipeline level.

How teams measure whether DevOps is working: DORA metrics

Google's DORA (DevOps Research and Assessment) program has published an annual "State of DevOps" report since Puppet Labs' original 2012 edition, tracking a small set of metrics that correlate with high-performing software teams: deployment frequency, lead time for changes, change failure rate, and a recovery-time metric (renamed "failed deployment recovery time" in DORA's 2023–2025 revisions, which also added a "rework rate" metric in 2024). Rather than ranking teams into simple performance tiers, DORA's 2025 update replaced tiers with seven descriptive team archetypes, reflecting that there's more than one legitimate way to practice DevOps well depending on a team's size, industry, and constraints.

A typical DevOps toolchain

There's no single required toolchain, but a common 2026 stack looks something like: source control and CI/CD through GitHub and GitHub Actions (or GitLab CI, Jenkins), containerization with Docker, orchestration with Kubernetes for larger deployments, infrastructure as code through Terraform or a cloud-native equivalent, and monitoring through tools like Prometheus, Grafana, or a cloud provider's built-in observability suite. None of these tools is DevOps by itself — they're the mechanisms that make the underlying practices and culture achievable at scale.

Frequently asked questions

What's next

DevOps isn't something you install — it's a way of organizing how a team builds, tests, and ships software, supported by specific practices like CI/CD and infrastructure as code. If you're evaluating tools to support a DevOps workflow, start with the pipeline layer: our guides to GitHub Actions and CI/CD and GitHub Actions vs. Jenkins both cover the automation foundation most DevOps toolchains are built on.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage