DevOps work moves through eight stages that form a loop: plan, code, build, test, release, deploy, operate, monitor. Each stage has a job to do and a handful of tools that do it. Learn the stages first. The tools are just the current way each stage gets done, and they change.
For the college passout or career switcher who has seen the wall of tool logos and wondered where to even start. You do not start with the logos. You start with the loop.
You type git push. That is one command. Between that keystroke and a stranger loading your change in a browser, a dozen things have to happen in order: your code has to be pulled onto a clean machine, turned into a runnable artifact, tested, checked for obvious security holes, packaged, shipped to a server, started in the right order, and watched to make sure it did not break anything. In a manual shop, a human does each of those steps by hand and prays. In a DevOps shop, a pipeline does them the same way every single time.
Part 1 defined DevOps as a way of working, and Part 2 showed the wall it tore down between developers and operations. This part is the map. Once you can name the stages and point to the tool doing each one, every tutorial you read after this stops being noise and starts landing in a slot you already understand.
The lifecycle is a loop, not a to-do list
The most common drawing of DevOps is the sideways figure eight, and it is drawn that way on purpose. Software is never finished. You plan a change, build it, ship it, watch how it behaves in production, and what you learn there feeds the next plan. The end of one trip through the loop is the start of the next. Here are the eight stages and what each one is actually for.
Plan, code, build, test
Plan is deciding what to build and writing it down where the team can see it. Code is the writing itself, tracked in version control so every change has an author and a history. Build turns human-readable source into something a machine can run: a compiled binary, a container image, a bundle. Test runs automated checks so a broken change gets caught by a machine at 2pm, not by a customer at 2am. These four are the developer inner loop, and a good pipeline runs the last three of them on every push.
Release, deploy, operate, monitor
Release is deciding a tested build is allowed to go out, often with a version tag and an approval. Deploy puts that build onto real infrastructure. Operate is keeping it running: scaling it, patching it, restarting it when it falls over. Monitor is watching metrics and logs so you know how it is behaving before your users tell you. The old world treated these four as a separate team’s problem. DevOps treats them as everyone’s problem, automated wherever a machine can do the job more reliably than a tired human at midnight.
The toolchain map, stage by stage
Here is the version-independent map. Read it as a phone directory: when someone says a tool name in a meeting, this tells you which stage they are talking about. The tools listed are common 2026 choices, not the only ones. Any single tool here can be swapped without changing the stage it fills.
| Stage | What it does | Common tools in 2026 |
|---|---|---|
| Plan | Track work and decisions | Jira, GitHub Issues, Linear |
| Code | Version control and review | Git, GitHub, GitLab |
| Build and Test | Turn source into an artifact, run checks | GitHub Actions, GitLab CI, Jenkins |
| Package | Bundle the app to run anywhere | Docker, container registries |
| Deploy and Operate | Run and scale containers | Kubernetes, ECS, Nomad |
| Provision | Create the infrastructure as code | Terraform, OpenTofu |
| Configure | Set up servers repeatably | Ansible |
| Monitor | Metrics, dashboards, alerts | Prometheus, Grafana, Datadog |
Every part after this one takes one row of that table and spends a whole article on it. Part 4 covers Linux and the command line, the surface all of these tools sit on. Part 5 is Git. Part 7 is CI/CD. Part 8 is Docker, and so on. If you understand this table, you understand the shape of the rest of the series.
What happens between git push and live
The abstract loop clicks once you watch it run on real code. A continuous integration pipeline is just a file in your repository that says: when someone pushes, run these steps on a fresh machine. Here is a minimal one for a Python project using GitHub Actions. Save it as .github/workflows/ci.yml.
name: ci
on: push
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: '3.13'
- run: pip install pytest
- run: pytest -qPush that with a passing test suite and the Actions tab shows a green run whose log ends like this:
Run pytest -q
........ [100%]
8 passed in 0.42s
Complete job
Job succeededThat single green check is the build and test stages of the loop, done by a machine, on every push, forever. Nobody had to remember to run the tests. That is the whole point.
The most common first failure is not a broken test. It is a broken file. YAML is picky about indentation, and if you use tabs or the wrong number of spaces you get this before any step even runs:
Invalid workflow file: .github/workflows/ci.yml#L5
You have an error in your YAML syntax on line 5The fix is boring and exact: two spaces per level, never tabs, and every list item under
steps starts with a dash at the same column. Paste your file into a YAML linter if it will not run. Ninety percent of first pipeline problems are indentation, not logic.The
ubuntu-latest runner in that file is not a fixed thing. GitHub points it at whatever Ubuntu it currently considers stable, and that changed under teams who pinned nothing. When it moved from 22.04 to 24.04, builds that quietly depended on an older system library started failing with no code change from anyone. Same story in Docker Engine 29, where the containerd image store became the default and a few teams found their old image tooling behaved differently overnight. Lesson for your first job: pin versions you actually depend on, and treat the word latest as a warning, not a convenience.You do not need the whole map on day one
Here is where I disagree with how the toolchain gets sold. Job posts list twenty tools and beginners assume they need all twenty running before they are employable. They do not. Most small teams ship perfectly good software with a Git repo, one CI pipeline, Docker, and a single managed database. Kubernetes solves the problem of running many containers across many machines with automatic healing and scaling. If you have one app on one server, Kubernetes is a second full-time job you volunteered for. Reach for it when the pain it removes is bigger than the pain it adds, not before.
The one place I would change what you learn is infrastructure as code. Terraform is the name everyone knows, but its license changed after IBM acquired HashiCorp in 2025, and new releases ship under the Business Source License rather than a fully open one. OpenTofu is the community fork under the Linux Foundation, stays open under MPL 2.0, and the commands are nearly identical. For a beginner in 2026 the syntax you learn transfers either way, so learn the concepts on whichever your future team runs and do not lose sleep over the logo.
| Tool | Do you need it on day one? | When it earns its place |
|---|---|---|
| Git | Yes, always | The first hour |
| CI pipeline | Yes, early | Second commit onward |
| Docker | Soon | When it works on my machine bites |
| Terraform or OpenTofu | Later | More than a couple of cloud resources |
| Kubernetes | Usually not | Many services across many machines |
Feedback: the half everyone forgets
Beginners obsess over the left side of the loop, the part that ships code, and ignore the right side that watches it. That is backwards. The reason the loop is drawn as a circle is that what you learn in production is supposed to travel back into the next plan. A slow page shows up in monitoring, becomes a ticket, becomes the next change. Without that return path you do not have DevOps. You have a fast way to ship code you never look at again.
In your first months, nobody expects you to run all eight stages. They expect you to know where a problem lives. When a deploy fails, is it a build issue, a test issue, or an infrastructure issue? Being able to say the pipeline is green so this is a deploy problem, not a code problem saves an hour of the whole team guessing. That single skill, placing a failure on the map fast, is what makes a junior look senior.
Walk me through what happens from a git push to your code running in production. There is no trick here. Name the stages in order, mention the tool doing each one, and call out where a failure would stop the line. Say the pipeline checks out the code, builds an artifact, runs tests, and only a green run gets deployed, then monitoring watches it live. Answer it as a loop and you have shown you understand DevOps, not just a tool.
Free, in about fifteen minutes. Make a new GitHub repository, add one Python file with a function and one test, and drop in the
ci.yml from above. Push it. Watch the Actions tab go green. Now break the test on purpose, push again, and watch it go red and block. You just ran the build and test stages of the loop with your own hands. How to check you did it right: the pull request or commit shows a green check when the test passes and a red x when it fails.Where the stages blur in a real team
The eight boxes are a teaching tool, not a wall chart your team follows in lockstep. In a real shop the stages overlap and some of them collapse into a single command. When you run a modern pipeline, build and test and scan often happen in one file, one after another, and a single failure anywhere paints the whole run red. Deploy and operate blur too: a Kubernetes cluster does not just place your container once, it keeps it running, restarts it when it dies, and moves it when a machine fails. That is deploy and operate happening continuously, not as separate steps a person triggers.
The stage that hides the most is plan. It rarely looks like a tool. It looks like a short conversation, a ticket, and a decision about what is worth building next. Newcomers skip past it because there is no logo to install, then wonder why their perfectly automated pipeline keeps shipping the wrong thing fast. Automation makes a good plan cheaper to deliver. It does nothing for a bad one. A team that deploys forty times a day and still misses what users need has automated everything except the one stage that decides whether any of it matters.
So when you read the map, hold it loosely. The order is real and the handoffs are real, but on any given Tuesday you might touch four stages in one pull request and never think about the boundaries between them. Knowing the boundaries is still what lets you find a problem fast when the smooth flow breaks.
Questions new DevOps engineers ask
Do I have to learn all these tools before I apply for jobs?
No. Learn Git and one CI tool well, understand what Docker does, and be able to explain the loop. Depth in the basics beats a shallow tour of twenty logos. Employers can teach you their specific stack. They cannot easily teach judgment about the stages.
Is CI/CD one thing or two?
Two. Continuous integration is the build and test half, run on every push to catch broken changes early. Continuous delivery or deployment is the release and deploy half, getting a good build out to users. Many teams have solid CI and manual deploys, and that is a fine place to start.
Terraform or OpenTofu?
The commands are nearly the same, so the skill transfers. OpenTofu stays open source under the Linux Foundation, while Terraform is under the Business Source License after the HashiCorp acquisition. Learn the concepts, run whichever your team runs, and know why the split exists because interviewers ask.
Where does cloud fit in this map?
Under all of it. The cloud is where deploy, operate, and provision happen. If those words are fuzzy, read the Cloud for Beginners series first, then come back and the deploy stage will make more sense.
Keep this map somewhere you can see it. Every tool you meet from here on slots into one of these eight stages, and knowing which slot is most of the battle. Next up is Part 4, where we get our hands on the Linux command line that every one of these tools runs on.
New here? Start with Part 1 on what DevOps actually means and Part 2 on the problem it solves. If the cloud pieces are new, the Cloud for Beginners series and the Python for Beginners series pair well with this one.
References
Kubernetes release information
GitHub Actions workflow syntax
OpenTofu documentation
Docker Engine 29 release notes
About The Author
DrJha