DevOps & CI/CD Zero to Hero: Ship Real Projects, Crack Inter

Every interviewer asks it, and most candidates fumble it: "Walk me through your Git workflow." Not the commands — the workflow. This lecture answers it the way senior engineers actually work, on one real feature (promo codes at checkout, SAVE10 = ten percent off) that gets branched, committed, raced against a teammate's hotfix, and collided with in the very same line of code — then resolved properly.

You will learn:

- The mental model: a commit is a snapshot with a parent, a branch is a movable pointer, HEAD is where you stand

- The daily workflow: pull, branch small, commit small, merge back through review, delete the branch

- Fast-forward merges — when the pointer simply slides and no merge commit exists

- Diverged histories and the merge commit with two parents

- A real merge conflict read marker by marker (`<<<<<<< HEAD` … `=======` … `>>>>>>>`), resolved by combining *both* intents, never by picking a side

- Rebase as the replay alternative — and the golden rule: never rebase a shared branch

One container is easy. Production is three copies at 3 a.m., one of them dead, and nobody awake. In this lecture you run the shop image from Lecture 1 the production way: a 19-line Deployment YAML read line by line, plus the 12-line Service that gives it one stable address. Then you delete a pod and watch the count heal itself, break the rollout with one wrong character (shop-app:v9 → ImagePullBackOff), diagnose it with two commands, and fix it with a one-line edit.

You will learn:

- Desired state: declare → compare → repair — the control loop that is the heart of Kubernetes

- Clusters, nodes, the control plane, and pods (mortal, replaceable, fresh pod = fresh address)

- The Deployment line by line: replicas, selector and labels, the pod template, image, containerPort

- The Service: one stable address, the traffic journey nodePort 30080 / port 80 → targetPort 8000

- Self-healing, scaling, and rolling updates that never trade working copies for broken ones

- The five mistakes: the broken name tag, the ghost edit in a live pod, the port mix-up, the moving image tag, and one replica called "production"

Your code works on your machine. Then someone has to build it properly, test it honestly, and deploy it — the same way, every time, with no human holding the checklist. That job belongs to one file in your own repository: the Jenkinsfile. Here you write a complete 24-line declarative pipeline, start to finish: checkout, build, test, package, and a deploy stage that only runs when it has earned the right.

You will learn:

- Pipeline as code: the file lives in the repo, reviewed and versioned like the app

- Declarative vs scripted — and why beginners should learn declarative first

- The anatomy: pipeline, agent (any / label / none), tools, environment, options, stages and steps in written order

- The when { branch 'main' } gate that keeps feature branches out of production

- The post block — always / success / failure / cleanup — and the four ways a build can end (SUCCESS, UNSTABLE, FAILURE, ABORTED)

- Build once, archive the artifact, promote that exact file — and the five mistakes, including the ungated deploy that has shipped unfinished code at real teams

Push the code on Friday, pray all weekend — that was the old release plan. In this lecture the shop app gets a machine that never forgets: a CI/CD pipeline in GitHub Actions, written as one YAML file that lives in the repository and tests every push on a clean machine.

You will learn:

- What CI and CD actually mean: a checkpoint nothing skips, not a ceremony

- The three words that run the whole system — workflow, job, runner (plus the step)

- The test job line by line: the file's one legal home in .github/workflows/, the on trigger for push and pull request, runs-on: ubuntu-latest, the strategy matrix across Python 3.10, 3.11 and 3.12, actions/checkout@v4, actions/setup-python@v5, and pytest -q as the moment of truth

- The deploy job and its guards: needs: test (a red run cancels the deploy — it never delays it), the condition that only a push to main may deploy, and the production environment

- Secrets done right: DEPLOY_TOKEN lives encrypted in the repository settings and masked in the logs — never in the code

- The last lock: branch protection requiring the test check, so the merge button itself does not work on red

- The five mistakes that quietly saw the gate off — and their fixes

Can one text file build an entire cloud — and then delete it again, cleanly? This lecture does it, with receipts at every step. You will write one Terraform file — a network (10.0.0.0/16, public + private subnets) and machines counted by a single variable — then run the real lifecycle with Terraform 1.9.8: init fetches three pinned providers, plan promises "6 to add, 0 to change, 0 to destroy", and apply delivers exactly six.

You will learn:

- Infrastructure as code: describe the destination; let the tool work out the journey

- Providers as translators, and the loop: init → plan → apply → plan again ("No changes" is the proof)

- Reading one complete file top to bottom: terraform block, variables, resources, outputs — and how dependency order is read out of the references themselves

- The state file interrogated: 7,255 bytes that hold the demo secret in clear text (found once by search) even though every screen masked it — while the configuration file itself holds zero copies

- Scaling by turning one dial (two machines → three, exactly two additions) and destroying all eight resources cleanly

- The five mistakes — and why every one of them is a memory failure, not a syntax error

Honest framing, stated in the lecture itself and kept here: no cloud account is used. The lifecycle runs on local providers with real files and real state; everything except the bill transfers to a real cloud account. You do not need a paid cloud account to take this lecture.

Everything in this course, working together. A small Python agent — four tools, one loop, a memory in a file — gets shipped like real software: one continuous pipeline from commit to production. You will write the three artefacts line by line: a four-instruction Dockerfile, a GitHub Actions workflow with three jobs chained by needs (test → build → deploy, deploy on main only), the same four stages as a Jenkinsfile, and a Kubernetes Job manifest — because a batch agent is a Job, not a Deployment (restartPolicy: Never, backoffLimit: 1).

Then the chain runs for real: the agent passes its own inspection, a ten-test pytest suite goes 10 passed, the pipeline runs Checkout → Test → Build → Deploy (dry run) all green, and the artefact — desk-agent-1.0.tar.gz, 2,015 bytes, SHA-256 fingerprinted — is the exact bytes that were tested. Then the proof: one expectation is broken on purpose (10:15 → 10:16) and the line stops at Test — 1 failed, 9 passed, no build, no artefact, deploy never reached.

You will learn:

- The four stages every pipeline is: checkout, test, build, deploy — each gated by the one before

- Matching the deployment shape to the work: Jobs for batch, Deployments for servers

- Versioning and fingerprinting artefacts so the bytes tested are the bytes shipped

- The five mistakes that make pipelines lie — and how a gate, not willpower, fixes each one

- The interview line: "My pipeline is four gated stages… a red suite physically cannot ship."

Honest framing, stated in the lecture itself: the build machine has no Docker daemon, Jenkins server or Kubernetes cluster, so the three artefacts are validated by parsing them and the pipeline stages are executed locally in the same order with the same gates; deploy is a labelled dry run.