What is DevOps?

You merge a pull request. Ten minutes later, real users see your change.

You did not copy files to a server. You did not restart anything.

Something did that work for you. That something is DevOps.

Two teams and a wall

Before DevOps, most companies had two separate teams.

• Developers wrote new features. Their goal was change.
• Operations ran the servers. Their goal was stability. To them, every change was a risk.

When developers finished a feature, they gave the code to operations. People called this "throwing it over the wall". Operations then installed it by hand, often at night, about once a month.

┌────────────────────────────────────────────┐
│                                            │
│     developers              operations     │
│    ┌──────────┐     ║║     ┌──────────┐    │
│    │ new code │ ──▶ ║║ ──▶ │ servers  │    │
│    └──────────┘     ║║     └──────────┘    │
│     "ship it"      wall    "keep it up"    │
│                                            │
└────────────────────────────────────────────┘

A monthly release held hundreds of changes. When something broke, nobody knew which change caused it. The fix took days.

┌───────────────────────────────────────────────────┐
│                                                   │
│    one big release         small releases         │
│    300 changes             one change each        │
│   ┌───────────────┐       ┌───┐ ┌───┐ ┌───┐       │
│   │ ░░░░░░░░░░░░░ │       │ ░ │ │ ░ │ │ ▓ │       │
│   │ ░░░░░░▓░░░░░░ │       └───┘ └───┘ └───┘       │
│   └───────────────┘                     ▲         │
│    bug: which one?                bug: this one   │
│                                                   │
│    ░ a change   ▓ the change with the bug         │
│                                                   │
└───────────────────────────────────────────────────┘

So what is DevOps?

DevOps is development plus operations. It is a way of working, not one tool. Three ideas make it work:

1. One team owns the software, from idea to users. Amazon's CTO, Werner Vogels, said it in 2006: "You build it, you run it."
2. Robots do the repeated work. A computer builds, tests and ships every change. Teams call this chain of automatic steps a pipeline. People review and decide.
3. Small changes, often. A small change is easy to check and easy to undo.

The DevOps loop

Every change goes around a loop with eight stages.

The left half is the "dev" side. The right half is the "ops" side. What the team learns in production goes into the next plan, so the loop never stops.

Here is the same loop with the tools a typical web team uses:

dev

ops

Plana ticket in Linear

Codegit push

Buildnext build

Testtests run by a robot

Releaseimage v1.4.2

Deploynew version to servers

Operaterun and scale on AWS

Monitorwatch errors and speed

ship

learn

• Plan. Decide what to build. This is a ticket in Linear or Jira.
• Code. Write the change, then push it to GitHub.
• Build. A robot turns your code into something that can run. For a Next.js app, this is next build.
• Test. The robot runs all the tests. One failed test stops the change.
• Release. The build gets a version number, like v1.4.2, and goes on a shelf. Nothing changes for users yet.
• Deploy. The new version goes to the servers. Now users get it.
• Operate. The servers run the app. They add more copies of it when traffic grows.
• Monitor. Dashboards and alerts watch for errors and slow pages.

Do not learn the tool names now. Each one gets its own lesson later.

You already use DevOps

As a frontend engineer, you already touch this loop. Here is a common setup for a Next.js team:

Someone set up every arrow in this picture. When an arrow breaks, someone fixes it.

That is DevOps work. This course shows you what happens inside each arrow.

Four questions this course answers

The ops side of a team spends its day on four questions. Each one is a part of this course.

┌─────────────────────────────────────────────┐
│                                             │
│   your app in production                    │
│   ├─ where does it run?        ch 2 3 4 6   │
│   ├─ how does code get there?  ch 5 7       │
│   ├─ how do we know it works?  ch 8         │
│   └─ how do we keep it safe?   ch 9         │
│                                             │
└─────────────────────────────────────────────┘

• Where it runs: servers, the cloud, containers and Kubernetes. Start at chapter 2.
• How code gets there: pipelines and infrastructure as code. See chapter 5 and chapter 7.
• How we know it works: monitoring, in chapter 8.
• How we keep it safe: security, in chapter 9.

How teams measure DevOps

Google's DevOps research group, called DORA, studies thousands of teams each year. It uses a few simple numbers to tell how well a team ships software:

In 2024, DORA added a fifth number: how often a team must ship an unplanned fix.

Read more

• What is DevOps? from AWS. Short and clear.
• The DevOps guide from Atlassian. Good pictures of the loop.
• DORA's delivery metrics from Google's research team.
• 10+ Deploys per Day, the 2009 Flickr talk. Watch the first ten minutes.

Next, you follow one commit from your laptop to a user's screen.