DevOps
DEV-ops
A set of practices that combines software development and IT operations to shorten the delivery cycle.
DevOps is the practice of breaking down the wall between the team that writes code (development) and the team that runs code (operations). Instead of developers throwing code over the fence and operators figuring out how to deploy it, both sides share responsibility for the entire lifecycle: writing, testing, deploying, monitoring, and fixing.
Before DevOps, releases were events. A team would spend months building features, then hand the code to an operations team that would spend days deploying it, often on a weekend. If something broke, developers blamed operations for deploying wrong, and operations blamed developers for writing buggy code.
DevOps changed this by automating the deployment pipeline and giving developers ownership of their code in production. Teams that practice DevOps deploy multiple times per day, monitor their own services, and respond to their own incidents. The result is faster delivery, fewer deployment failures, and faster recovery when things break. Tools like Docker, Kubernetes, Terraform, and GitHub Actions are the technology layer, but DevOps is fundamentally a culture change.
Examples
A company adopts DevOps practices.
The company used to deploy monthly. Each deploy took 8 hours and required a Change Advisory Board meeting. After adopting DevOps, they automate testing and deployment with CI/CD pipelines, containerize services with Docker, and monitor with Datadog. Within a year, they deploy 20 times per day. Each deploy takes 8 minutes. Failed deploys are automatically rolled back. The CAB meeting is replaced by automated policy checks.
A DevOps engineer builds a deployment pipeline.
The engineer creates a GitHub Actions workflow: on every merge to main, the code is built, tested, containerized, pushed to ECR, deployed to a staging ECS cluster, smoke-tested, and then promoted to production. The entire pipeline runs in 12 minutes. If any step fails, the pipeline stops, the team is notified in Slack, and production is untouched.
DevOps culture changes how teams handle incidents.
At 2 AM, the monitoring system detects increased error rates. Instead of paging an operations team unfamiliar with the code, the on-call developer who wrote the service is paged. They know the codebase, can read the logs, and push a fix in 15 minutes. The incident goes from detection to resolution in 22 minutes instead of the old average of 4 hours.
In practice
Read more on the blog
Frequently asked questions
What is the difference between DevOps and SRE?
DevOps is a philosophy: break down silos, automate everything, share ownership. SRE (Site Reliability Engineering) is Google's implementation of that philosophy, with specific practices like error budgets, SLOs, and toil budgets. All SRE teams practice DevOps principles, but not all DevOps teams use SRE frameworks. SRE adds quantitative rigor: instead of 'deploy faster,' SRE says 'maintain 99.95% availability while deploying 50 times per week.' SRE is DevOps with math.
Is DevOps a role or a practice?
It started as a practice but has become a role at many companies. 'DevOps engineer' usually means someone who builds and maintains CI/CD pipelines, manages infrastructure, and automates operational tasks. Purists argue that having a separate DevOps team defeats the purpose, because it recreates the silo between dev and ops. The healthiest approach is embedding DevOps skills across all engineering teams while having a platform team that builds shared infrastructure tools.
Related terms
Continuous integration and continuous deployment: automating code testing and delivery to production.
Managing servers, networks, and cloud resources through code files instead of manual configuration.
Site Reliability Engineering: an engineering discipline focused on keeping systems running reliably at scale.
Lightweight, portable packages that bundle application code with all its dependencies.
Continuously checking system health using metrics, dashboards, and alerts to detect problems.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.