CI/CD & GitHub Actions — The Map

Right now, this very website you’re reading rebuilt and republished itself the last time I pushed code — no human touched a server. By the end of this track you’ll understand exactly how, and be able to build the same thing. This is the lecture that turns “deployment” from magic into machinery.

How this track is built

Three lectures, same shape every time so your brain knows where to look: 🎯 objectives → mental model → core content → ⚠️ misconceptions → 🧪 lab → ✅ self-check → 📚 graded resources → 🔑 key terms. Read for the model, do the lab, then answer the self-checks out loud. Lecture, then problem set — the MIT rhythm.

1. Overview (you are here) — what automation, CI/CD, and Actions actually are
2. Anatomy — events, jobs, steps, actions, runners; write your first workflow
3. Advanced — secrets, permissions, OIDC, caching, concurrency, security; then we dissect this site’s real deploy pipeline line by line

🎯 Learning objectives

By the end of this lecture you can:

1. Explain what problem CI/CD solves and why every serious team uses it.
2. Define Continuous Integration, Continuous Delivery, and Continuous Deployment — and say how they differ.
3. Describe what GitHub Actions is and where it physically runs.
4. Name the five core nouns — event, workflow, job, step, runner — and how they nest.
5. Locate the real workflow runs of this site and read whether they passed.

The problem (why this exists)

Imagine you finish a feature. To ship it to users, by hand, you must:

1. Run the tests        →  did I break anything?
2. Run the linter       →  is the style consistent?
3. Build the project    →  does it even compile?
4. Log into a server    →  ssh, credentials, the right folder
5. Copy the files up     →  hope you copied the right ones
6. Restart the service   →  cross fingers
7. Check it's actually live

Do this 10 times a day, across 5 teammates, and three things go wrong every single time:

• Humans forget steps. “I forgot to run the tests” is how bugs reach production.
• Humans aren’t consistent. Your laptop has different software than mine. “Works on my machine” is a real category of outage.
• Humans are slow and serial. Nobody wants to babysit a 7-step ritual.

The core insight

Every step above is deterministic — the same inputs always produce the same outputs. Anything deterministic and repeated is a job for a machine, not a person. CI/CD is simply “let a clean, identical robot do the ritual, the same way, every time.”

Mental model: the tireless robot assistant

Picture a robot that lives in a brand-new, empty room (a fresh computer). Every time you push code, it:

1. Wakes up in that empty room.
2. Pulls a clean copy of your code from GitHub.
3. Follows your checklist exactly — install, test, build, deploy.
4. Reports ✅ or ❌.
5. Burns the room down and forgets everything.

The “burns the room down” part is the magic. Because the robot starts from nothing every time, there’s no leftover state, no “but it worked yesterday.” If it passes in the empty room, it’ll pass on any machine. That clean-room guarantee is the whole reason CI/CD eliminates “works on my machine.”

What is CI/CD?

Three terms people throw around — here’s the honest breakdown:

Delivery vs Deployment — the one-word difference

Continuous Delivery = always ready to ship (human pushes the button). Continuous Deployment = actually ships itself. This site uses Continuous Deployment: merge to main → users see it ~70 seconds later, zero human steps.

What is GitHub Actions?

GitHub Actions is GitHub’s built-in automation platform. It watches your repository for events (a push, a pull request, a schedule, a button press) and, when one happens, runs workflows — your checklists — on computers that GitHub provides and manages for you.

Two things make it powerful:

• It’s right where your code already lives. No separate CI server to set up (the old world needed a tool called Jenkins running on a machine you maintained). Actions is just a .github/workflows/ folder in your repo.
• GitHub rents you the robots. You don’t own or patch the build machines — GitHub spins up a fresh virtual machine (a runner), runs your job, and throws it away.

It’s free for you — really

For public repositories, GitHub Actions minutes are unlimited and free. (Private repos get a monthly free allotment, then pay-per-minute.) This entire site’s CI/CD costs ₹0 — exactly the kind of free leverage worth mastering.

The five nouns (the whole vocabulary)

Everything in Actions is these five things nested inside each other:

EVENT  (something happened: "push to main")
  └─ triggers a WORKFLOW   (one .yml file: "Deploy to GitHub Pages")
        └─ contains JOBS    ("build", then "deploy")
              └─ each runs on a RUNNER  (a fresh VM GitHub gives you)
              └─ and is a list of STEPS  ("checkout", "install", "build")
                    └─ a step is either a shell command OR an ACTION (reusable plugin)

We’ll spend the next lecture turning each of these from a word into something you can write.

How this connects to you, right now

You already have a working example sitting in your own repo:

• The event: you git push to main.
• The workflow: .github/workflows/deploy.yml.
• The jobs: build (compile the site) → deploy (publish to GitHub Pages).
• The runner: a fresh Ubuntu VM GitHub spins up.
• The result: darshan-1820.github.io/Career-sprint updates itself.

By Lecture 3 you’ll read that file the way you read a sentence.

⚠️ Common misconceptions

Things beginners get wrong

• “CI/CD is one tool.” No — it’s a practice. GitHub Actions, GitLab CI, Jenkins, and CircleCI are different tools that all implement it.
• “Actions only deploys websites.” Deployment is one use. Actions also runs tests, lints code, builds mobile apps, publishes npm packages, sends Slack messages, runs nightly data jobs — anything scriptable.
• “The robot keeps my files between runs.” It does not. Every run starts from an empty machine. This trips up everyone once. (It’s also the feature, not a bug — see the mental model.)
• “If it’s green, the code is correct.” Green means your checks passed. If you wrote weak tests, CI happily ships bad code. CI is only as good as the checklist you give it.

🧪 Lab — see your real pipeline

You don’t need to write anything yet. Just observe:

1. Open https://github.com/Darshan-1820/Career-sprint/actions.
2. You’ll see a list of workflow runs — one per push.
3. Click the latest one. Notice the two jobs: build and deploy.
4. Click build → expand the steps. Read them top to bottom. That’s the robot’s checklist.
5. Find the total time. (Mine runs in ~70 seconds.)

What to notice

Each step has a ✅ and its own duration. When something breaks, the failing step turns ❌ red and the run stops there — so you instantly know which part of the ritual failed. That pinpointing is half of why CI/CD is so valuable.

Here’s that same pipeline as a run you can step through — watch the all-green path, then the one that fails at tests and stops dead:

✅ Self-check

Answer out loud first, then expand.

Check Yourself

Cover the answers. Say each one out loud before you peek.

📚 Graded resources

• 🟢 Beginner — GitHub Actions: Quickstart — 10-min official walkthrough. Do this after Lecture 2.
• 🟢 Beginner — GitHub’s “Understanding GitHub Actions” — the same five nouns, from the source.
• 🟡 Intermediate — Martin Fowler, Continuous Integration — the canonical essay on why CI exists. Theory, not tooling. Worth a slow read.
• 🟡 Intermediate — The Twelve-Factor App — factors V (Build/release/run) and X (Dev-prod parity) are CI/CD’s philosophical backbone.
• 🔴 Advanced — Google SRE Book, Release Engineering — how a company shipping billions of times thinks about this. Aspirational; skim now, reread in a year.

Why AI can’t do this for you

You can ask AI to write a workflow file — and it will. But when the deploy goes red at 11pm, debugging it requires a mental model of what the robot is doing in that empty room: which job failed, what state it had, why the runner couldn’t find a file. That model only forms by building and breaking pipelines yourself. The syntax is cheap; the model is the career skill.

🔑 Key terms

Next: Anatomy of a Workflow + Your First One →