The DevOps Toolchain

When people first look at DevOps, the sheer number of tools is scary. There are hundreds of logos, and every blog post seems to push a different one. The good news: you do not need to learn them all. DevOps is really a small set of jobs that need doing — store code, build it, ship it, run it, watch it — and each job has a handful of popular tools that do the same thing in slightly different ways. This page maps the common tools to the job they do, so you can see the shape of the whole picture and pick one tool per job to start with.

Tools are interchangeable — learn the concept first

The single most important idea on this page: the tool is not the skill. The skill is understanding what the tool does and why. A CI server (Continuous Integration server — software that automatically builds and tests your code every time you push it) does the same job whether it is called Jenkins, GitHub Actions, or GitLab CI. If you understand “build and test on every push,” switching tools later is a weekend, not a career.

So when you see a giant tool list, do not panic. Group the tools by purpose. Learn one tool per purpose deeply. The concepts transfer; the YAML syntax (a text format for config files) does not, and that is fine.

When NOT to learn a new tool: if your job, your tutorial, and your team already use Tool A, do not switch to Tool B because it is trendy. Switching tools to chase hype is the fastest way to learn nothing well. Master one, then branch out.

The stages and their tools

DevOps follows a lifecycle: plan, code, build, test, release, deploy, operate, monitor. Each stage has go-to tools. Here is the map.

Stage	What the job is	Popular tools (2026)	Start with
Plan	Track work and decisions	Jira, Linear, GitHub Issues	GitHub Issues
Source control	Store and version code	Git + GitHub / GitLab	Git + GitHub
Build / CI	Compile, test on every push	GitHub Actions, Jenkins, GitLab CI	GitHub Actions
Artifact storage	Keep built packages/images	Docker Hub, GitHub Packages, Nexus	Docker Hub
Containers	Package an app + its deps	Docker, Podman	Docker
Orchestration	Run many containers reliably	Kubernetes, Docker Compose, Nomad	Docker Compose
Infrastructure as Code	Create servers from text files	Terraform, OpenTofu, Pulumi	Terraform
Config management	Set up software on servers	Ansible, Chef, Puppet	Ansible
CD / deploy	Push releases out automatically	Argo CD, GitHub Actions, Spinnaker	GitHub Actions
Monitoring	Measure health and metrics	Prometheus + Grafana, Datadog	Prometheus + Grafana
Logging	Collect and search logs	Loki, ELK (Elasticsearch/Logstash/Kibana)	Loki

Notice the “Start with” column. That is a complete, modern, mostly free toolchain you can learn end to end. You do not need the rest yet.

How the pieces fit together

Here is the typical flow for one code change, from your laptop to production:

You write code and git push to GitHub (source control).
The push triggers GitHub Actions (CI), which runs your tests and builds a Docker image.
The image is pushed to a registry (Docker Hub or GitHub Packages — a storage shelf for images).
Argo CD or another deploy tool notices the new image and rolls it out to Kubernetes (orchestration), which runs your containers.
Prometheus scrapes metrics, Grafana draws dashboards, and you get paged if something breaks.

Separately, Terraform created the servers/cloud resources in the first place, and Ansible installed the base software on them. Those run less often — usually only when infrastructure changes.

A tiny taste on Ubuntu

You do not need a cloud account to start. Install Git and Docker on Ubuntu 22.04/24.04 LTS and you can practice locally.

sudo apt update
sudo apt install -y git
sudo apt install -y docker.io
sudo systemctl enable --now docker
sudo usermod -aG docker $USER   # so you can run docker without sudo (log out/in after)

Check it worked:

git --version
docker --version

Output:

git version 2.43.0
Docker version 27.5.1, build 9f9e405

Gotcha: after usermod -aG docker $USER you must log out and back in (or run newgrp docker) for the new group to take effect. Until then docker commands will say “permission denied.” Also note: anyone in the docker group effectively has root — only add trusted users.

Picking between two common choices

Most “which tool?” questions come down to a small trade-off. Two you will hit early:

Question	Option A	Option B	Pick which
CI server	GitHub Actions (hosted, zero setup)	Jenkins (self-hosted, very flexible)	Actions if your code is on GitHub and you want simple; Jenkins for full control or air-gapped networks
Run containers	Docker Compose (one machine, simple)	Kubernetes (many machines, self-healing)	Compose for a single server or learning; Kubernetes only when you truly outgrow one box

For almost every beginner: GitHub Actions + Docker Compose is the right answer. Kubernetes is powerful but heavy, and reaching for it too early is the most common DevOps mistake.

Best Practices

Learn one tool per job, deeply. Breadth comes later; the concepts transfer between tools.
Resist Kubernetes until you need it. Docker Compose runs real workloads on one server with far less complexity.
Prefer hosted/managed tools when starting (GitHub Actions, Docker Hub) so you spend time on concepts, not on babysitting servers.
Keep your infrastructure in code (Terraform/Ansible) from day one — never click around a cloud console for anything you want to repeat.
Pick tools your team or tutorial already uses. Compatibility and help beat novelty every time.
Treat config as code: put your .github/workflows, Dockerfile, and Terraform files in Git alongside the app.
Don’t chase logos. A logo wall is a map of jobs, not a to-do list.