Lesson 10 — DevOps & Deployment

How code goes from a laptop to running for real users — CI/CD, containers, IaC.

IT Landscape Module 3

The journey of one line of code

• 20 years ago — this took weeks of manual handoffs between teams.
• In 2026 — it can take 10 minutes, end to end, fully automated.
• The cluster of tools and habits that makes that possible is called DevOps.

What “DevOps” actually means

• Less a tool, more a culture.
• “The people who write the code also own running it in production.”
• Replaced the old “developers throw code over a wall to ops” model.
• The toolchain we’ll tour today is what grew around that culture.

Tool 1 — Version control as the trigger

• Every change starts with a git push (see Lesson 05).
• The remote — GitHub, GitLab, Bitbucket — fires events on every push and every pull request.
• Those events are what kicks off everything else in the pipeline.

Tool 2 — CI (Continuous Integration)

• On every push, an automated pipeline runs your test suite, lints the code, builds the artifacts.
• If anything fails, the change is blocked.

Popular CI hosts (as of 2026):

• GitHub Actions — dominant.
• GitLab CI, CircleCI, Buildkite.
• Jenkins — the old guard, still huge in enterprise.

What a CI run looks like

• A green check or a red X next to every pull request.
• Click in → see the log of every step: clone repo, install dependencies, compile, run tests.
• Each step shows its own duration; the whole run usually finishes in 5–20 minutes.

A real CI config (illustrative)

A minimal GitHub Actions workflow, lives at .github/workflows/ci.yml:

on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm test

Tool 3 — CD (Continuous Deployment / Delivery)

• Same machinery, one step further: after tests pass, automatically deploy.
• Continuous Delivery — every successful build is ready to deploy (human clicks the button).
• Continuous Deployment — every successful build is deployed, automatically.

Tool 4 — Containers (Docker)

• Solved the “works on my machine” problem once and for all.
• Docker is the brand most people learn first.
• A container image is a frozen filesystem + config + run-command.
• Often <100 MB, starts in <1 second, identical across laptop / CI runner / production server.

Tool 5 — Orchestrators (Kubernetes & friends, as of 2026)

• When you have 100 containers across 50 machines, you need something to schedule them, restart them when they crash, and route traffic.
• Kubernetes (a.k.a. k8s) is the heavyweight standard.
• Lighter alternatives: Nomad, AWS ECS, Fly.io, Render, Railway, Cloud Run (Google).

Tool 6 — IaC (Infrastructure as Code)

• Terraform (HashiCorp) / OpenTofu (the open fork) — cross-cloud standard.
• Pulumi — same idea, written in Python / TypeScript.
• AWS CloudFormation — the AWS-native one.
• Ansible — for configuring existing servers.

Your cloud setup becomes version-controlled, reviewed, and reproducible.

Tool 7 — Monitoring & observability

Once it’s running, you need to know if it’s healthy. Three telemetry families:

• Logs — lines of text. Datadog, Loki, CloudWatch, Splunk.
• Metrics — numbers over time. Prometheus + Grafana, Datadog.
• Traces — one request’s path across services. Jaeger, Honeycomb, Datadog APM.

Recap

• The pipeline: commit → CI → container → orchestrator → monitoring.
• The culture: whoever writes it, owns it.
• The goal: deploy small changes, often, safely.