DEVOPS-01-001-P · Primer — What is DevOps

The idea in one sentence

DevOps merges the people who write the software with the people who run it, so one team owns a service from the first commit all the way to the customer.

Why it exists

For decades, developers wrote code and threw it over a wall to a separate operations team who deployed and babysat it. Devs were rewarded for shipping features fast; ops was rewarded for keeping things stable — so their incentives fought each other, and every release became a negotiation. The classic result: a change breaks at 2 a.m., the pager goes to an on‑call ops engineer who has never seen the code and cannot fix it, while the developer who wrote it sleeps through the outage. Think of it like a restaurant kitchen where the chef prepares a dish and then hands it off to a dishwasher who never tasted it; when the dish is burnt, the chef is nowhere to fix it. DevOps exists to delete that wall and align both goals — speed and reliability — inside a single team that feels both consequences.

How it works

DevOps is a set of practices that let one team move fast without breaking things, wired into a tight feedback loop. Continuous integration (CI) has every developer merge small changes into shared code many times a day, and an automated pipeline builds and tests each one. Continuous delivery (CD) then packages every change that passes and pushes it toward production, so releases are boring and frequent instead of rare and terrifying. Infrastructure as code (IaC) describes the servers and networks in a reviewed git repo rather than hand‑clicked in a console, and observability — metrics, logs, traces — lets the same team watch the change behave live. Build, test, release, observe, learn, repeat — that loop is the whole machine.

Concrete worked example

A team commits a change that adds a new API endpoint. The CI pipeline runs 5 unit tests (all pass) and a 10‑minute integration test suite that catches a regression in latency, causing the build to fail. The developer fixes the bug, pushes again, and the pipeline now succeeds in 12 minutes. CD automatically creates a Docker image, tags it v1.2.3, and pushes it to the registry. IaC scripts spin up a new Kubernetes pod with the image, perform a canary rollout to 5 % of traffic, and observability dashboards show latency staying under 200 ms. After 30 minutes of healthy metrics, the rollout is completed to 100 % of users. The whole end‑to‑end cycle from commit to production took 45 minutes, with zero manual steps.

@@MERMAID@@

The one gotcha

DevOps is not a job title you hire for and not a tools pipeline you can buy — its heart is one cultural rule: you build it, you run it. The team that writes a service also carries its pager and owns its uptime, so there is no wall left to throw a release over. That ownership is what actually changes behavior: when you feel the pain of your own 3 a.m. page, you write more reliable code, better alerts, and a real rollback the next day. If you create a “DevOps team” that sits between Dev and Ops, you have simply added a third wall and renamed the old one.

The one-line takeaway

One team builds it and runs it — no wall.

Where you'll meet it

You'll meet DevOps in GitHub Actions and GitLab CI pipelines, in Terraform and Kubernetes manifests, in Prometheus and Grafana dashboards, and on every on‑call rotation you join. The DORA / Accelerate research made it measurable — deploy frequency, lead time, change‑failure rate, and time to restore — and Google's SRE practice turned "run it" into an engineering discipline with error budgets. Wherever a team ships its own code and answers its own pager, you're looking at DevOps.

Named concepts: DevOps, you build it you run it, CI/CD, infrastructure as code