Core DevOps practices and the DORA metrics

The practices that make DevOps real

Culture is the foundation, but a team also needs concrete habits. These practices appear in almost every DevOps team. You will learn each of them in depth later in this course.

Continuous delivery versus continuous deployment

The two terms share the short form CD, which confuses many people. In continuous delivery, the software is always in a releasable state, but a person decides when to push it to production. In continuous deployment, there is no human step: if all automated checks pass, the change goes live. Banks and regulated companies often choose continuous delivery with an approval step. Many web companies use continuous deployment.

Shift left

Picture the SDLC drawn from left (plan) to right (operate). "Shift left" means moving testing and security checks earlier, to the left. Instead of a security review one week before launch, the pipeline scans every commit for known vulnerable libraries and leaked passwords. A bug found while coding costs minutes; the same bug found in production can cost days and customer trust.

Small batches and trunk-based development

A batch is the amount of change released together. Small batches mean less risk and faster feedback. Trunk-based development supports this: everyone works on short-lived branches (hours or a day or two) and merges into the main branch, called trunk, many times a week. Long-lived feature branches that stay apart for a month end in painful merge conflicts.

Feature flags: separate deploy from release

A feature flag (or feature toggle) is a switch in the code that turns a feature on or off without a new deployment. Teams deploy unfinished code with the flag off, so trunk stays releasable. Later they switch it on for 1% of users, then 10%, then everyone. If something goes wrong, they switch it off in seconds.

if flags.is_enabled("new_checkout", user_id):
    show_new_checkout()
else:
    show_old_checkout()

Measuring delivery: the DORA metrics

DORA (DevOps Research and Assessment) is a long-running research programme, now part of Google Cloud, that publishes the yearly State of DevOps report. Its research found four key metrics that separate high-performing teams from low performers. Two measure speed and two measure stability.

The key finding is that speed and stability go together. The best teams deploy more often AND fail less AND recover faster, because small batches and automation help both.

DORA keeps refining its model. Later reports added a fifth measure about operational reliability, renamed "time to restore service" to "failed deployment recovery time", and added further measures. The four keys above are still the standard starting point; check the current DORA report on dora.dev for the latest names and benchmark ranges.

A worked example

Over 10 days a team made 5 deployments. Deployment frequency is 5 / 10 x 7 = 3.5 per week. Lead times were 4, 24, 2, 30 and 6 hours; sorted they are 2, 4, 6, 24, 30, so the median is 6 hours. Two deployments failed, so change failure rate is 2 / 5 = 40%. They took 45 and 15 minutes to restore, so the mean time to restore is 30 minutes. The 40% failure rate is the clear problem to work on.