Part 17 of 17 · ~2 min
Common Mistakes Worth Remembering
- Treating "CI" as done once tests run, without ever actually gating a deploy on them passing (no
needs:/equivalent dependency wired between the test job and the deploy job).
- Rebuilding the artifact separately for staging and production instead of promoting the exact same one — you end up testing something subtly different from what ships.
- Running a full, slow end-to-end suite on every single push instead of layering fast checks (lint, unit tests) on every push and reserving the heaviest suite for pre-merge or a schedule.
- Hardcoding secrets directly in a pipeline YAML file instead of the platform's secrets store, or granting a fork-triggered PR workflow access to production secrets.
- No rollback plan — or one that exists on paper but has never actually been exercised before the incident that needs it.
- Choosing a deployment strategy (rolling, in particular) without making database migrations backward compatible for the mixed-version window it creates.
- Conflating "deployed" with "released" — shipping a risky change straight to 100% of users instead of behind a feature flag or a canary that could have caught it at 5%.
- No automated verification after a deploy completes — assuming a green pipeline run means the application is actually healthy in production.
CI/CD is the delivery mechanism for the artifacts covered in Docker Fundamentals — a container image is exactly the kind of build artifact this reference describes building once and promoting through environments. And the deployment topology a pipeline is shipping to (one deployable unit, or several independent services) shapes what "a pipeline" even means — see Microservices vs. Monolith for how that choice multiplies (or doesn't) the pipelines a team maintains. This project's own deploy path (Vercel, triggered by a GitHub push) is a simple real-world example — see STATUS.md in the repo for where that stands. Practice the underlying logic — tests as gates, not suggestions — in the code lab.