Automated builds
🏠The everyday picture
A bakery with a written recipe and a timer makes the same bread every morning, whoever is on shift. A bakery that relies on one person's memory has good days and bad days.
📘What it really is
- An automated build turns source code into something runnable, the same way every time, on a clean machine:
- install exact dependencies from the lock file:
npm ci(nevernpm installin CI, which may change versions); - check types:
npx tsc --noEmit; - check style and common mistakes:
npm run lint; -
build the frontend (
npm run build) and the API container image (Module 69). -
Clean machine matters: a build that only works on your laptop (because of a file or setting there) fails here, which is exactly the point. It proves the project's instructions are complete.
-
Reproducible builds: pinned versions (lock files,
node:22-slimnotnode:latest), no downloads of "whatever is newest" during the build. -
Caching dependencies makes builds faster without changing the result.
- Artifacts: the build's outputs (a container image tagged with the commit, the frontend's
distfolder) are stored, so later steps deploy exactly what was built and tested ("build once, deploy many", Module 70).
🖱️Try it
On a fresh clone of your CRM in a new folder (or in your lab), run only the commands written in your README to build it.
Note every missing step or hidden assumption, and fix the README or scripts until a clean build works first time. Add
"typecheck", "lint" and "build" scripts to package.json if they're missing.
✅Quick check
Why use npm ci instead of npm install in a build?
Show the answer
It installs exactly what the lock file says, so every build uses the same versions.
Why build on a clean machine?
Show the answer
To prove the build doesn't depend on anything hidden on one person's computer.