Test, gate, and build on autopilot — every push checked automatically, before it can break anything.
Module 9 · GitHub Actions, bridging into the DevOps Lab.
Intermediate CI/CD Includes Lab ~50 minPrerequisites: Module 8, a free GitHub account. Deep dive: DevOps Lab: CI/CD.
You've been running lint, tests, and builds by hand. A pipeline runs them for you, automatically, on a clean machine, every time you push. That's the difference between "I remembered to check" and "it's impossible to merge broken code."
| Term | Plain meaning |
|---|---|
| CI (Continuous Integration) | Every push is automatically linted, tested, and built. |
| CD (Continuous Delivery) | Passing builds are automatically packaged — and, optionally, deployed. |
| Workflow | The YAML file describing the steps to run. |
| Runner | The clean machine GitHub spins up to run your workflow. |
An AI can introduce a subtle break at any moment. CI catches it on the very next push, on a machine that isn't "your machine" — so "works for me" never reaches anyone else.
A workflow is one YAML file in .github/workflows/. This runs your gates on every push:
The DevOps Lab CI/CD module and its sample-app/.github/workflows/ci.yml use exactly this pattern, extended with a Docker build-and-push. Have the assistant draft yours — then read it, because a workflow is code too.
Once CI is green, CD takes the next step: build the container image from Module 8 and publish it to a registry, so a deployable artifact exists for every passing commit. Full auto-deploy comes in Module 10 — here we make sure the image is always built and ready.
The payoff: turn on branch protection so a pull request can't merge into main unless CI passes. Now the gates from Modules 6–7 aren't a suggestion — they're enforced by the platform, for you and any future collaborator (human or AI).
Spec → build with the loop → tests → gates → CI enforces them on every push. Broken or unsafe code physically can't reach your main branch. That's the professional standard, running itself.
You'll push the vault to GitHub, add a CI workflow that runs your gates on every push, and watch it pass — then prove it blocks a break.
Your containerized snippet-vault from Module 8 and a free GitHub account.
Create a new repo on GitHub, then:
Review it, commit, and push.
Open the Actions tab on GitHub. Your workflow runs on the clean runner — watch lint, test, and build go green.
On a branch, deliberately break a test, push, and open a pull request. CI should go red and block the merge. Fix it, push again, watch it turn green. Then add a CI status badge to your README.md.
In REFLECTION.md: what did CI catch that you might have merged locally? Commit and push.
Your GitHub repo URL. Self-check:
ci.yml runs lint, tests, and build on every pushREFLECTION.md updated| Term | Plain meaning |
|---|---|
| Pipeline | The automated sequence of checks/builds a push goes through. |
| Workflow | The YAML file defining that sequence (GitHub Actions). |
| Runner | The fresh machine that executes the workflow. |
| Branch protection | A rule that blocks merges unless checks pass. |
| Registry | Where built container images are stored (e.g. GHCR). |
A CI pipeline that runs your gates on every push, blocks broken code from merging, and builds a deployable image — your engineering standards, enforced automatically.
Next up: Module 10 — Deploy + Infrastructure as Code. We take that built image live, and define the infrastructure it runs on as version-controlled code — reproducible deployments, no clicking around.