Mostly harmless, conspicuously useful
The Hitchhiker's Guide to Becoming a DevOps Engineer
A DevOps engineer automates the path from a developer's laptop to a running production service and back again, which is a perfectly reasonable ambition until you remember that the path crosses two teams who have historically communicated by parking ticket, a build system whose mood is weather, and a release calendar that believes "Friday afternoon" is a defensible punctuation. You learn to translate "we shipped it" into reviewed commits, pipelines, tests, artifacts, deployments, rollback plans, and telemetry that proves the shipping happened to someone other than the engineer who shipped it. DevOps is not a team name, a tool, or a certificate; it is the realisation that development and operations share one set of consequences, and that the gap between them is where most outages file their paperwork. This guide travels from reading one repository's history to setting organisation-wide delivery strategy, with practical stops at source control, continuous integration, release engineering, infrastructure as code, observability, and the recurring discovery that a pipeline marked "green" is merely a pipeline that has not been asked a follow-up question. The grand objective is dependable delivery; the daily evidence is usually a change that reaches production without anyone holding their breath, an alert that names its cause before the customer does, and a release note that survives contact with the actual change.
Level 1 · Novice
Read the commit history before asking the main branch to recount civilisation
You inspect repositories, branches, commits, pull requests, and pipeline definitions without changing them, learning how a perfectly polite build can tour every test, pass them all, and deploy exactly what was requested rather than what was meant.
You begin with read-only artifacts: a repository's commit log, branch structure, pull request history, CI pipeline definition, build results, and an artifact registry expressing recent opinions. A commit is a recorded change to a tracked set of files; a branch is a named line of development; a pull request is a proposal to merge one line into another, accompanied by review, checks, and occasionally a comment thread that has begun to develop its own foreign policy. You review these with developers, testers, and an experienced engineer so everyone can trace how a change reaches the main branch before anyone merges a wall that turns out to be load-bearing.
Suppose a deployment slows after a release. In a read-only view of the CI system, you copy the exact pipeline run, inspect which jobs ran, how long each took, what artifacts they produced, and whether the final deploy step actually deployed the artifact the tests ran against or a different one assembled later by a helpful script. You record elapsed time, job order, artifact hashes, and whether the pipeline's green badge celebrates tests that ran against a build that never reached a customer. That evidence lets a developer fix a missing promotion step or escalate a caching problem; one brisk pipeline rerun is an anecdote with good posture, not a diagnosis.
Words from the spaceship manual, translated
- Repository
- A version-controlled store of files and their history, where every change is recorded with an author, a timestamp, and a message that may or may not describe the change. It is the institution's archive, except entries are refused immediately if they conflict rather than debated in committee.
- Pull request
- A proposal to merge one branch into another, accompanied by review, automated checks, and discussion. It follows its wording with magnificent literalism, so a pull request titled "fix typo" that also rewires the auth layer is a pull request that expects a long conversation.
- CI pipeline
- A defined sequence of automated jobs that build, test, and package a change on every push, rather like an itinerary that reveals a planned twelve-minute scenic detour through a flaky integration test before departure.
- Artifact
- A versioned, hashable output of a build — a container image, a package, a binary — that can be promoted through environments. The artifact is what actually gets deployed; the commit is what the artifact claims to be, and the gap between them is where surprises live.