Ship software the way real teams ship it.

DevOps is not a tool and not a job title you buy with a certificate. It is a way of working where the people who write software and the people who run it stop throwing work over a wall and instead own it together, end to end.

The old way: developers wrote code, zipped it up, and handed it to an operations team who tried to make it run in production. When it broke at 2am, each side blamed the other. DevOps collapses that wall. The same team builds it, tests it automatically, ships it automatically, and watches it in production.

Three ideas carry the whole field:

• Automate everything that repeats — building, testing, deploying.
• Make small changes often — ten tiny safe releases beat one terrifying big one.
• Measure what happens — you cannot fix what you cannot see.

Servers do not have a mouse. Almost every server on earth runs Linux, and you talk to it by typing. The terminal feels intimidating for a week, then becomes the fastest tool you own.

The commands you will use every single day:

• pwd — where am I? (print working directory)
• ls -la — list everything here, including hidden files
• cd projects — move into a folder; cd .. goes back up
• cat file.txt — print a file; less file.txt to scroll
• mkdir, cp, mv, rm — make, copy, move, remove
• grep "error" app.log — search inside files

Two things trip up every beginner on Linux: permissions and installing software.

Permissions

Every file has an owner and a set of permissions: read (r), write (w), execute (x). When a script "won’t run", it usually just needs permission: chmod +x deploy.sh makes it executable. When you see Permission denied, you either need sudo (run as administrator) or you are touching a file you do not own.

Packages

You do not download installers on Linux — you use a package manager. On Ubuntu/Debian that is apt:

• sudo apt update — refresh the catalogue
• sudo apt install git — install software

Git is the time machine for your code. It records every change so you can go back, see who changed what and when, and let many people work on the same project without overwriting each other.

Working without Git — final.js, final_v2.js, final_REAL_final.js — is a nightmare you will never go back to.

The daily rhythm is three steps:

• git add . — stage your changes (choose what goes in)
• git commit -m "Add login form" — save a snapshot with a message
• git push — send it to the shared server (GitHub)

A branch is a parallel copy of your project where you can try something without touching the working version. This is what lets teams move fast without breaking things.

The pattern: main is always the stable, working code. To add a feature you branch off, do your work, then merge back when it is ready.

• git checkout -b feature/payments — create and switch to a new branch
• work, add, commit as normal
• git checkout main then git merge feature/payments — bring it back in

GitHub is where your Git history lives online so a team can share it. It adds one hugely important idea on top of Git: the pull request (PR).

A pull request says: "here is my branch, please review it before it goes into main." A teammate reads the changes, comments, and approves. This review step is where quality and knowledge-sharing happen — and later, where automated tests run before anything merges.

"It works on my machine" is the oldest excuse in software. Docker killed it.

A container packages your application with everything it needs — the code, the runtime, the libraries, the settings — into one sealed box that runs identically on your laptop, a colleague’s laptop, and a server in a data centre.

People confuse containers with virtual machines. A VM carries a whole operating system (heavy, slow to start, gigabytes). A container shares the host’s kernel and carries only your app (light, starts in a second, megabytes). You can run dozens of containers where you could run two or three VMs.

Two words to keep straight: an image is the recipe (a saved blueprint); a container is a running instance of that image. You build an image once and run many containers from it.

You describe the image in a Dockerfile — a plain list of steps:

• FROM node:20 — start from an official Node.js image
• COPY . /app — copy your code in
• RUN npm install — install dependencies
• CMD ["node","server.js"] — how to start it

Real apps are not one container. A typical web app is a frontend, a backend API, and a database — three containers that must talk to each other. Starting and wiring them by hand is painful.

Docker Compose lets you describe the whole stack in one docker-compose.yml file and start it all with one command: docker compose up.

Two abbreviations you will hear constantly. CI (Continuous Integration): every time someone pushes code, it is automatically built and tested, so broken code is caught in minutes, not weeks. CD (Continuous Delivery/Deployment): once tests pass, the code is automatically shipped to a server.

Together they form a pipeline: push → build → test → deploy, with no human doing it by hand. Humans make mistakes when they deploy manually at midnight; a pipeline does the same safe steps every time.

Let us get something on the internet. The simplest real deployment: a cheap Linux server (a VPS) running your container.

The steps, which you will later automate:

• Rent a VPS (DigitalOcean, Hetzner, Contabo — from a few dollars a month)
• Connect with ssh user@your-server-ip
• Install Docker, copy your image across, docker run it
• Point a domain name at the server’s IP

Your app needs settings that differ between your laptop and production: database passwords, API keys, which URL to call. Two rules keep you safe.

Never hard-code secrets in your code. A password committed to Git is a password leaked forever — people scan GitHub for exactly this. Keep secrets in environment variables instead, loaded at runtime.

Keep environments separate. You want a development setup, maybe a staging copy for testing, and production for real users — each with its own config, so a test never touches real customer data.

GitHub Actions runs your pipeline for free, right where your code already lives. You describe it in a YAML file under .github/workflows/ and it triggers on events — most often "on every push".

A workflow is made of jobs, and each job is a list of steps. A step either runs a command or uses a pre-made action.

A real pipeline has stages that run in order, and a later stage only runs if the earlier one passed. This is your safety net.

• Build — compile the code, build the Docker image
• Test — run automated tests; if any fail, stop here and alert
• Deploy — only reached on the main branch, only if tests passed

You make jobs wait for each other with needs:, so deploy has needs: [build, test]. Broken code physically cannot reach production because the deploy step never runs.

Three things make pipelines fast and safe.

Caching: downloading dependencies on every run wastes minutes. Cache them so repeated runs are quick — a real cost saving on limited free minutes.

Artifacts: the output of a build (a compiled app, a built image) can be saved and passed to the next job instead of rebuilt.

Secrets: your deploy needs a server key or a registry password. Store these in GitHub’s encrypted Secrets, never in the YAML. Reference them as ${{ secrets.SSH_KEY }} — they are masked in logs so they never leak.

One container on one server is easy. But what happens when that server dies at 3am? Or when traffic triples during a campaign and one container cannot cope? Or when you need to update without downtime?

Kubernetes (K8s) is the system that manages containers across many servers for you. You tell it the desired state — "I want 3 copies of my app running at all times" — and it makes that true and keeps it true. A container crashes? It starts a new one. A server dies? It moves the work elsewhere. This is called self-healing.

Three core objects run almost everything in Kubernetes.

• A Pod is the smallest unit — usually one running container.
• A Deployment manages Pods: it keeps the number you asked for running and handles rolling updates.
• A Service gives your Pods a stable address, because individual Pods come and go. It also load-balances traffic across them.

To run safely in production, Kubernetes needs to know three more things.

ConfigMaps hold non-secret settings (which API to call, feature flags). Secrets hold sensitive values (passwords, keys), kept separate from your images.

Health checks (probes) let Kubernetes know if a Pod is actually healthy. A liveness probe asks "are you alive?" — if not, restart it. A readiness probe asks "are you ready for traffic?" — if not, hold traffic back until it is. Without these, Kubernetes would send users to a Pod that is still starting up or silently frozen.

Clicking around a cloud console to create servers, networks and databases works once — and is a disaster to repeat, document or recover. Infrastructure as Code (IaC) means you write down your infrastructure as text files, version it in Git, and let a tool build it.

Terraform is the most popular IaC tool. You describe what you want (resources); Terraform figures out how to create, change or destroy them to match.

Three concepts run Terraform.

• A provider is the plugin for a given platform (AWS, GCP, Azure, DigitalOcean).
• A resource is one thing you want to exist — a server, a database, a DNS record.
• The state file is Terraform’s memory of what it has already built, so it knows the difference between "create new" and "change existing".

The Terraform workflow is deliberately safe.

• terraform plan — shows you exactly what will change before anything happens. Always read this.
• terraform apply — makes the changes.
• terraform destroy — tears it all down cleanly (great for temporary test environments, and for not paying for idle servers).

Modules let you package a reusable piece of infrastructure (say, "a standard web server + firewall") and use it many times with different inputs — the same don’t-repeat-yourself principle as functions in code.

Once your app is live, you are flying blind unless you watch it. Two kinds of data matter: metrics (numbers over time — CPU, memory, request rate) and logs (the detailed text record of what happened).

Prometheus collects metrics; Grafana turns them into dashboards you can actually read. The four golden signals to watch on any service:

• Latency — how slow are responses?
• Traffic — how much demand?
• Errors — how many requests fail?
• Saturation — how full are your resources?

A dashboard nobody looks at is useless at 3am. Alerting pushes a message (email, SMS, Slack) when something crosses a threshold — "errors above 5% for 5 minutes".

The art is to alert on symptoms users feel, not on every twitch. Alert on "the site is returning errors", not on "CPU hit 80% for 10 seconds". Too many false alarms and your team learns to ignore alerts — the most dangerous failure of all, called alert fatigue.

Here is where everything connects. Your capstone project ties the whole course into one real system:

• Code lives in Git, reviewed through pull requests
• A GitHub Actions pipeline builds, tests and ships on every merge to main
• The app runs as a Docker container, orchestrated by Kubernetes
• The infrastructure is defined in Terraform
• Prometheus and Grafana watch it, with one real alert wired up

When you can point an employer at this — "I built this, here is the repo, here is the live dashboard" — you are no longer learning DevOps. You are doing it.