DevOps is a way of working that joins software development (Dev) and IT operations (Ops) into one flow. Developers and operators share goals, tools and responsibility for software in production, and automation replaces manual hand-offs. The result is smaller, more frequent and safer releases. Site reliability engineering (SRE) is a closely related discipline that focuses on keeping those systems reliable. As a new engineer you'll work inside both, often without the labels.
The problem DevOps solves#
DevOps makes more sense once you see what came before it. In a traditional company, two teams own two halves of the job, and their goals conflict.
| Team | Owns | Measured on |
|---|---|---|
| Development | Design, code, tests, new features | Shipping features |
| Operations | Servers, networks, deploys, monitoring, security patches | Keeping things stable |
Developers want change. Operations wants stability, and change is the main cause of outages. So releases become rare, large and risky. Code is "thrown over the wall" to Ops, and when it breaks, each side blames the other.
DevOps removes the wall. The same team, or teams with shared goals, builds the software and runs it. In practice that means:
- Shared ownership. The people who write a service also see its alerts and help fix it.
- Automation. Builds, tests, deploys and infrastructure changes run from code, not from checklists.
- Small batches. Many small changes are easier to test, review and roll back than one big one.
- Fast feedback. Monitoring and users tell you quickly whether a change worked.
- Blameless learning. After an incident you fix the system, not the person. See root cause analysis.
Some companies have a "DevOps engineer" role. Those engineers usually build the pipelines, infrastructure code and monitoring that let product developers ship and run their own services. DevOps itself is a culture, not a job title.
The DevOps loop#
Those practices turn into a repeating cycle of work. DevOps is often drawn as an infinite loop: delivery feeds operations, and operations feeds the next plan. The stages are:
- Plan: agree on a prioritized backlog of small pieces of work.
- Code: write the change and commit it to a shared repository.
- Build: compile and package the code automatically in CI.
- Test: run automated tests on every change.
- Package: store a versioned artifact, such as a container image, in a registry.
- Release: deploy the artifact with automated tooling that can also roll it back.
- Operate: run and scale the service and its infrastructure.
- Monitor: watch metrics, logs and user feedback. Feed what you learn back into planning.
Stages 3 to 6 are the CI/CD pipeline. The CI pipelines note covers its stages, and deployment strategies covers safe releases. Stage 8 is observability.
Traditional SDLC vs DevOps#
The loop's stages aren't new; the traditional way of building software has them too. The difference is how often you go through them. A traditional software development lifecycle (SDLC) runs each phase once, in order, for a large scope. DevOps runs all phases continuously, in small slices.
| Stage | Traditional SDLC | DevOps |
|---|---|---|
| Requirements | Fixed up front | Refined continuously from feedback |
| Design | Detailed design before coding | Modular, evolves with the code |
| Development | Long branches, late integration | Small commits, merged daily with CI |
| Testing | Mostly manual, after development | Automated, on every change |
| Deployment | Manual, rare, error-prone | Automated, frequent, reversible |
| Monitoring | Ops watches after release | Team watches continuously, with alerts |
| Time to market | Weeks to months | Hours to days |
Why SaaS made this easier#
One shift in the industry made the right-hand column practical. When customers install software on their own servers, the vendor can't push a fix. Every update waits for the customer's IT team. With software as a service (SaaS), the vendor runs the only copy. It can deploy small changes many times a day, watch the effect, and roll back at once. That's the setting where DevOps practices pay off most.
DevSecOps and shift-left security#
Security used to be a separate review at the end, much like Ops used to be. DevSecOps adds security to the DevOps loop as a shared job, not a final gate before release. Shift left means moving checks earlier in the loop (to the left on a timeline that runs from plan to production), where problems are cheaper to fix.
In practice, shifting left means adding automated checks to the pipeline:
- Dependency scanning: flag libraries with known vulnerabilities.
- Static analysis (SAST): find risky patterns in source code, such as SQL built from strings.
- Secret scanning: block commits that contain keys or passwords.
- Container and infrastructure scanning: check images and IaC files for known flaws and unsafe settings.
- Dynamic testing (DAST): probe the running app, for example with OWASP ZAP.
- Compliance as code: encode policies, for example for PCI DSS or GDPR, as automated checks.
The web app attacks note covers the flaws these tools look for.
DevOps vs SRE#
The opening called SRE closely related to DevOps. Both share the same goal: ship fast and stay reliable. They differ in emphasis. DevOps is a broad culture that grew from the community; Patrick Debois organized the first DevOpsDays conference in 2009. SRE began at Google in 2003 under Ben Treynor Sloss. It's a concrete practice: you treat operations as a software engineering problem.
| DevOps | SRE | |
|---|---|---|
| What it is | Culture and set of practices | Engineering discipline and often a role |
| Main focus | Flow: fast, safe delivery | Reliability: availability, latency, scale |
| Key tools | CI/CD, IaC, automation | SLOs, error budgets, incident response |
| Measures | Deploy frequency, lead time, change failure rate | SLOs met, downtime, toil reduced |
| Ownership | Everyone owns the whole flow | Shared, with SREs as reliability experts |
What SREs do#
SRE turns "be reliable" into numbers and rules.
- Define SLIs and SLOs for each service, and agree on an error budget. When the budget runs out, risky releases pause. See SLIs, SLOs and error budgets.
- Reduce toil. Toil is manual, repetitive work that grows with traffic, such as restarting servers by hand. SREs automate it away.
- Run incident response and blameless postmortems. See the on-call process.
- Build self-healing systems, such as automatic restarts, failover and rollback.
Seeing both in one deploy#
The two can sound abstract apart, so take one web app release. The DevOps side builds the pipeline that tests and deploys it, and the Terraform code that creates its servers, database and load balancer. The SRE side sets an SLO such as 99.95% availability, watches latency and error rate during the rollout, and writes the automation that rolls back if the error budget burns too fast. Many teams do both, and the line between them is blurry.
Key takeaways#
- DevOps joins development and operations through shared ownership, automation, small batches and fast feedback.
- The DevOps loop is plan, code, build, test, package, release, operate, monitor, then back to plan.
- A traditional SDLC runs each phase once for a big scope. DevOps runs every phase continuously in small slices.
- DevSecOps shifts security left with automated scans in the pipeline.
- SRE applies software engineering to operations, using SLOs, error budgets and toil reduction to keep systems reliable.