DevOps path: 59 days from commit to production
Fifty-nine one-hour sessions, one a day, from 3 November to 31 December, in four modules. You start from zero, alone, with free tools; you finish with a small application that goes from a commit to production through a pipeline you built, documented and broke on purpose.
Who it is for, and where it leads
For anyone who wants to learn how software is built, shipped and kept running, with no diploma and no prior experience: no Linux, no programming, no networking assumed. DevOps is a culture and a set of practices before it is a job title; the jobs it leads to are usually called DevOps engineer, site reliability engineer (SRE), platform engineer or cloud / infrastructure engineer. Many people reach them from a support, sysadmin or developer first job: this path gives you the ground and the proof to apply for those first jobs or junior DevOps roles.
What a self-taught learner shows a recruiter on 31/12 is not a certificate but a public repository: four deliverables (one per module) and a final project with its pipeline, its tests, its infrastructure as code, its dashboard, its runbook and a postmortem of an incident you caused and fixed. A recruiter can read the history of your commits; make them worth reading.
The method, the same every day
| Time | Phase | What you do |
|---|---|---|
| 20 min | Theory | The session's lesson on the module page, with its exercises: answer before you read on. |
| 30 min | Practice | Hands-on work in your Linux machine, step by step, then the day's prompt for your AI. |
| 10 min | Recap | Three lines in your notebook, then redo the day's exercise without notes. |
The recap is the phase people skip, and it is the one that makes things stick: recalling from memory is what anchors knowledge.
The tools, installed once (day 1)
- A Linux machine: a Debian or Ubuntu virtual machine in VirtualBox, or WSL 2 on Windows, or Linux itself. Everything in the path runs there.
- Git and a code editor (VS Code or its free build VSCodium).
- An account on a forge with CI: GitHub (GitHub Actions is free on public repositories) or a Forgejo instance (Codeberg runs one, or you host your own: see Homelab 8).
- Docker Engine from day 20; Ansible, OpenTofu, kind and kubectl when their module comes.
- A notebook: one Markdown file per day, in a Git repository of its own (you will version it from day 10).
8 GB of RAM is enough until module 3; Kubernetes with kind and the monitoring stack are more comfortable with 16 GB. Everything is free and runs on your own machine: no cloud account, no credit card.
Learning with an AI, without letting it learn for you
This path is learnt with an AI as tutor, preferably a model running on your own machine (see your first local model). It is a tutor, not a ghost-writer:
- ask it to quiz you, to explain an error message, to review a script or a pipeline you wrote;
- never paste its answer as your work: type it yourself, line by line, and be able to explain every line;
- check what it says against the official documentation: it can be wrong with full confidence, invent a flag or a module that does not exist, or describe an old version.
Every session ends its practice with a line "With your AI:" giving the day's prompt. From module 1 on, a note "Let an agent do it:" also shows what a coding agent (Claude Code, Kimi Code, OpenFox, a local model with tools) can take over for a task you have already done by hand once, and what you still check yourself.
Prompting for DevOps work
A prompt for operations work is a ticket for a colleague who has never seen your machine. A good one has:
- Role and context: who the model plays, what system it is (Debian 13, Docker Engine, GitHub Actions…, with the versions
--versionprints). - Task: one verb, one result.
- Constraints: what must not happen (no
sudo, idempotent, no secret in the file, pinned versions). - Inputs: the real error message, the real file, the real command output, pasted, not summarised.
- Output format: one file, a diff, a numbered list of commands, a table.
- Examples: one line of what a good answer looks like, if the format matters.
- How you will check: "I will run
shellcheck,--check --diff,tofu plan": tell it, and do it.
Each module has a lesson on prompting for its own work (day 8: scripts, day 26: pipelines, day 35: infrastructure as code, day 50: incidents). A model's answer is a proposal until a command, a test or the documentation has confirmed it.
The golden rule
One hour every day beats seven hours on Sunday. If you miss a day, do not catch up the next day: shift everything by one day, and trim module 4. The dates shown assume a start on 3 November; only the order and the regularity matter.
The four modules
Each module is one page and ends with a deliverable worth putting in a portfolio. Tick a module once all its sessions are done; your progress stays in your browser.
Recommended free resources
- Pro Git, by Scott Chacon and Ben Straub, free online (module 1)
- The Missing Semester of Your CS Education (MIT): shell, scripting, Git (module 1)
- The Linux Command Line, by William Shotts, free PDF (module 1)
- Learn Git Branching, an interactive Git game (module 1)
- Linux Foundation — Introduction to DevOps and Site Reliability Engineering (LFS162), free, self-paced
- Kubernetes Basics, the official tutorial (module 3), and Killercoda for browser labs
- Google's SRE books, free online (module 4)
- DORA: the research on software delivery performance (modules 1 and 4)
- roadmap.sh — DevOps, to see where each topic sits
The end-of-path checklist, to tick on 31/12
- I explain what DevOps is, where it comes from and how its results are measured.
- I write a bash script that checks its errors and passes ShellCheck.
- I branch, merge, rebase and resolve a conflict in Git, and I review a pull request.
- I write a CI pipeline that lints, tests, scans and builds an image.
- I build a small, non-root container image and run a stack with Compose.
- I configure a machine with an idempotent Ansible playbook and describe infrastructure with OpenTofu.
- I deploy, expose, update and roll back an application on Kubernetes.
- I keep secrets out of Git and out of logs.
- I read metrics, logs and traces, I define an SLO and an alert.
- I run an incident and write a blameless postmortem.
- I have a public, documented project that goes from commit to production.
A box that will not tick is not a failure: it is the list of what you work on next.
- 1DevOps module 1: the culture, Linux, the shell and GitDays 1 to 14: where DevOps comes from and how it is measured, the Linux command line, permissions, processes, bash scripting, the network seen from a terminal, Git in depth, branching workflows and code review.
- 2DevOps module 2: CI/CD pipelines and containersDays 15 to 28: continuous integration and delivery, the GitHub Actions and Forgejo Actions syntax, tests in the pipeline, runners, containers from Dockerfile to registry, Compose, and release strategies.
- 3DevOps module 3: infrastructure as code, Kubernetes and secretsDays 29 to 42: configuration management with Ansible, infrastructure as code with OpenTofu, Kubernetes from the first Pod to rollouts, Helm and GitOps, and keeping secrets out of Git.
- 4DevOps module 4: observability, incidents, security, and the final projectDays 43 to 59: metrics, logs and traces with Prometheus, Grafana, Loki and OpenTelemetry, SLOs and alerts, incident handling and blameless postmortems, security in the pipeline, then a small app taken from commit to production.