1.1. From Manual Toil to Event-Driven Automation
💡 First Principle: Computers are better than humans at doing the same thing the same way every time — so any step of software delivery that must happen reliably and repeatedly should be described once, in code, and triggered by events rather than by memory.
Think about what shipping software looks like without automation. Someone remembers to run the tests. Someone builds the release on their laptop — with whatever tool versions happen to be installed there. Someone copies files to a server, ideally the right ones. Every "someone" and "ideally" in that sentence is a failure point, and none of it leaves an audit trail. When the build breaks on Friday at 5pm, nobody can say with certainty what was different this time.
Continuous integration and continuous delivery attack this by turning delivery steps into code that reacts to events. Push a commit → the tests run. Open a pull request → a reviewer sees a green check or a red X before merging. Tag a release → a build is produced on a clean machine, from a known commit, with logs anyone can read. The pipeline is an assembly line: the product moves through fixed stations, each station does one job, and a defect stops the line early, when it's cheapest to fix.
GitHub Actions is GitHub's implementation of this idea, with one distinguishing property that shapes everything on the exam: it lives inside the repository platform. The events are repository events (pushes, pull requests, issues, releases), the permissions model is GitHub's permissions model, and the configuration is just files in .github/workflows/, versioned like any other code. That tight integration is why a workflow can react to nearly anything that happens on GitHub — and why misconfiguring one can expose the repository itself.
⚠️ Common Misconception: "CI/CD is just running tests automatically." Testing is one station on the line. The exam's scope — and the tool's — covers the whole delivery path: building, packaging, publishing, deploying, releasing credentials to deployment jobs, and enforcing who may approve what along the way.
Reflection Question: Your team runs tests manually before merging and "it works fine." What specifically do you lose compared to event-triggered tests — even if nobody ever forgets to run them?
