DevOps Roadmap 2026: Nine Steps from Linux and Git to Kubernetes and GitOps

This piece goes through the roadmap stage by stage and adds checked context where it matters. That context covers Kubernetes and Helm version support, GitOps definitions, the DORA metrics, GitHub Actions security, and the Linux "Copy Fail" bug. It also notes where the original claims need more care.

Why the order matters​

Pillitteri groups the nine stages into three phases:

• Foundations: Linux and the shell, Git, and scripting (Bash and Python).
• Delivery: cloud, CI/CD, infrastructure as code (IaC), and containers.
• Orchestration: Kubernetes with Helm, and GitOps with Argo CD.

Each stage has a "passing criterion". This is a sentence describing something you should be able to do without copying it from a guide. These are the author's suggested benchmarks, not validated standards. They are still a sensible way to check yourself against the "I watched a tutorial" illusion.

Kubernetes sits at the end for a reason. CNCF's 2025 Annual Cloud Native Survey, published January 20, 2026, found that 82% of container users run Kubernetes in production, up from 66% in 2023. The denominator matters. It counts container users, not all organizations or all software teams. The same survey reported that 58% of "cloud native innovators" use GitOps principles extensively, against 23% of "adopters". That fits the idea that GitOps is a late-stage maturity step, not a starting point.

Measuring progress with DORA​

DORA, the research program behind the DevOps delivery metrics, now uses five measures. Its own history page says they fall into two groups:

• Throughput: change lead time, deployment frequency, and failed deployment recovery time.
• Instability: change fail rate and deployment rework rate.

Change lead time runs from commit to successful production deployment. DORA says the fifth metric, rework rate, was added in 2024. The recovery metric was renamed in 2023 to focus on failures caused by a change to production.

Pillitteri says Git, pipelines, containers, IaC and GitOps each move these numbers. Treat that as a plausible mechanism, not a guaranteed result. DORA metrics describe team outcomes, not the effect of any single tool. A git revert can restore declared configuration quickly. Recovery time still depends on how fast a team notices the failure and on the rest of its process.

The foundations: Linux, Git and scripting​

Linux and the shell. Most servers, cloud VMs, containers and Kubernetes nodes run Linux. The roadmap asks you to learn permissions, processes, systemctl and journalctl. It adds networking basics (ports, DNS, TCP) and the tools ss, curl and dig. It also recommends SSH keys and a throwaway VM you can break. The passing test is to work out within about five minutes whether an unresponsive service is a process, port, DNS or disk problem.

Patching your practice machines is worth doing. The article cites the "Copy Fail" flaw. CERT-EU's advisory describes a high local privilege escalation vulnerability, CVE-2026-31431, publicly disclosed on 29 April 2026. It carries a CVSS score of 7.8. It affects the Linux kernel's algif_aead module and relates to a 2017 optimisation. CERT-EU said at publication that no distribution had yet shipped a fixed kernel package. As interim mitigation it advised disabling the algif_aead module, and it said to prioritise Kubernetes nodes and CI/CD runners exposed to untrusted workloads. It also recommended blocking AF_ALG socket creation with seccomp policies in containerised workloads. Check your distribution's current security tracker for fixed packages, because the advisory reflects the situation on 30 April 2026.

Git. Git is the ledger for everything after it. The advice is small commits that explain why, short-lived branches, reviewed pull requests, and git revert to undo a published commit without rewriting shared history. One rule is worth remembering. A secret committed to a repository should be treated as burned, even if a later commit deletes it, because it stays in the history. Revoke it and issue a new one. A .gitignore file only keeps untracked files out. It does not remove anything already committed.

Scripting. Bash glues commands together. Python takes over when you need real logic or structured data. The "rewrite past fifty lines" rule is the author's rule of thumb, not a standard. Three habits matter more:

1. Open with set -euo pipefail.
2. Quote your variables.
3. Make the script safe to run twice (idempotence).

Run generated scripts through ShellCheck. It catches exactly the quoting and pipe-failure traps that AI assistants tend to miss silently. It reduces risk but does not prove a script is correct.

The delivery stages​

Cloud. AWS, Azure and Google Cloud use different names for the same blocks: identity, networking, compute, storage, managed databases and billing. The advice is to pick the one that dominates the job ads you care about. Set a spending alert before creating any resource. Check prices in the provider's official calculator, not in an AI answer. The "tear everything down with one command" criterion is a good goal. In practice, cleanup can miss resources, so check the bill and the account afterwards.

CI/CD. The pipeline lives in a versioned file beside the code. GitHub Actions, GitLab CI and Jenkins do similar jobs. GitHub's documentation says use of the standard GitHub-hosted runners is free and unlimited on public repositories. Private repositories draw from included compute and then per-minute rates. These plan details can change, so confirm them before you rely on them.

The pipeline is also an attack surface, and GitHub's own guidance shows why the roadmap stresses minimal token permissions. Workflows triggered by pull_request_target run with elevated trust, receiving the base repository's GITHUB_TOKEN and access to secrets. The risk comes when a workflow checks out a fork's pull request code and then runs it. GitHub calls this a "pwn request". Its docs say a default policy blocking pull_request_target in public repositories is in evaluate mode. Enforcement is scheduled for December 2, 2026 for affected repositories. If you maintain public repositories, review the policy insights now.

On pinning, GitHub's guidance is that a full-length commit SHA is the immutable way to reference an action, because tags can move. The article also names the "Megalodon" CI/CD campaign and a CVSS 10 Gemini CLI flaw as examples of toolchain risk. Both are second-hand here. Verify affected and fixed versions in the original advisories before acting on either.

Infrastructure as code. Terraform and its fork OpenTofu share the same workflow. The step that matters is plan. Read it in full before every apply, paying attention to anything marked as replaced or destroyed. In teams, keep state in a shared location with locking. The licensing difference is real. HashiCorp moved Terraform's future releases to the Business Source License in August 2023, and OpenTofu is a Linux Foundation fork of the earlier MPL-licensed code. "Either is fine for learning" is reasonable. A company should check the actual license terms against its use case, and this is not legal advice. Ansible then handles what is inside the machines that Terraform creates.

Containers. Learn the Dockerfile, how layers affect the build cache, volumes, networks, and Compose for small multi-container projects. The concrete precautions are:

• Run as a non-admin user.
• Use precise version tags instead of latest.
• Add a .dockerignore file.
• Keep secrets out of layers.

Check base image versions on the official registry. Models often remember old numbers.

Kubernetes, Helm and GitOps​

Kubernetes. The objects to understand are Pod, Deployment, Service, Ingress, ConfigMap, Secret, persistent volumes, probes, resource requests and limits, namespaces and RBAC. A local cluster with kind or minikube is enough for study. The article's workflow is --dry-run=client -o yaml to generate a skeleton, then kubectl diff, apply, rollout status, logs and describe. The passing test is to diagnose a CrashLoopBackOff pod and roll back a bad release.

On versions, the official releases page says the project maintains release branches for the three most recent minor releases: 1.37, 1.36 and 1.35. The latest 1.37 patch listed is 1.37.1, released September 15, 2026. Version 1.34 has an end-of-life date of 2026-10-27, so it is already out of support. Learners should pick a supported minor line. Practise an upgrade later, since that is a useful exercise.

Helm. The article says Helm 3 is "still supported until February 2027". That needs a qualifier. Helm's end-of-life notice says a final, limited Helm 3 feature release was set for September 9th, 2026, with security patches continuing through February 2027. The Helm project's history page says Helm 4.0.0 shipped on November 12, 2025 at KubeCon. Secondary reports say the last Helm 3 minor, 3.22.0, appeared around September 9–10, 2026. The Helm notice says only security patches will be released, on demand, and no other bug fixes. The exact end date is February 10, 2027. As of today, Helm 3 is in a security-only window, not full support. New learners should start with Helm 4.

Teams with existing pipelines have some checking to do. A migration guide notes that Helm 4 requires domain names only for helm registry login, and renames flags such as --atomic to --rollback-on-failure. That is a secondary source, so confirm it against Helm's own Helm 4 documentation. Charts reportedly need no changes, while CI scripts may.

GitOps with Argo CD. OpenGitOps v1.0.0 defines four principles: declarative desired state, versioned and immutable storage with full history, automatic pulling by software agents, and continuous reconciliation. The roadmap uses Argo CD to show this. It runs in the cluster, watches a Git repository, and pulls the cluster toward what Git says. A pull model can keep cluster credentials inside the cluster. It does not remove secret management. Secrets still must not sit in plain text in Git.

The typical layout uses two repositories, one for application code and one for configuration. CI builds the image and updates the tag in the configuration repository. Argo CD applies it, and rollback is a git revert. The passing test is to change an image tag in Git and watch the cluster follow. Then delete a resource by hand and, with automatic sync on, watch it return.

Observability, security and AI​

Observability stays in view from the first stage. The roadmap names three signal types: metrics, logs and traces. It suggests Prometheus and Grafana for a first dashboard. The advice on alerts is to page on user-facing symptoms such as rising errors or slow responses. Alerting on every CPU wobble teaches people to ignore alerts. The CNCF survey also ranks OpenTelemetry as the second-highest-velocity CNCF project.

On AI assistants, the author's position is sensible and not hype. Use them to explain a command before you run it, review a plan, manifest or workflow, and critique your own attempt. Don't paste secrets. Verify flags, field names and versions in official documentation. Always read the Terraform plan, the Kubernetes diff and the pipeline permissions in full. Those are the three places where an AI mistake costs the most. An AI explanation, however convincing, is not evidence that a change is safe.

The capstone project​

The roadmap ends with one growing project: a small flash-poll service, a Python API with a database. It grows stage by stage:

1. It runs on a Linux VM with pull requests.
2. It gets backup and status scripts.
3. Its network and machine are described in Terraform.
4. A pipeline tests, builds and publishes the image.
5. It runs as two Kubernetes replicas with probes and per-environment Helm values.
6. A separate configuration repository drives Argo CD sync, with rollback by revert.
7. It gains a three-chart dashboard, one useful alert and dependency scanning.

The result is a portfolio piece: a green pipeline, a readable plan and a documented rollback. It shows skills better than a list of certificates. It does not guarantee a job.

Common mistakes​

• Collecting tools without a project to tie them together.
• Starting at Kubernetes because it appears most in job ads, which skips Linux and containers.
• Following old tutorials without checking the official documentation for changed flags and versions.
• Leaving cloud resources running after a session.
• Committing an .env file because "it's only a test".

For small projects, the roadmap says Kubernetes is usually unnecessary at first. A few containers can sit on one machine with Docker Compose. Kubernetes becomes worth it when you need scale, zero-downtime releases and many applications to govern.

Where to start tomorrow​

1. Install a Linux VM.
2. Create an empty repository.
3. Write one small script that does something useful, and make it safe to run twice.

Everything else builds on that. The roadmap's central point holds up well: each stage consumes the output of the last.