CI, Build Reproducibility & Deployment
Automate checks and make each deployment traceable and reversible.
Learning objectives
By the end of this lesson, you should be able to:
- Explain the key concepts and when they are useful.
- Apply the concepts to a realistic engineering scenario.
- Identify common failure modes and choose a practical mitigation.
- Complete the assignment and explain your design decisions.
Core concepts
A reliable pipeline checks formatting, linting, type errors, unit tests, integration tests, and production builds before publishing. Pin runtime versions and lock dependencies. Separate build-time configuration from secrets and keep deployment artifacts tied to a commit SHA.
Worked example
A GitHub Actions workflow should fail fast on quality checks and publish only from a trusted branch. Secrets belong in repository or environment secrets, never committed to YAML or exposed in client-side variables. Use health checks and a rollback path.
Engineering principles
- Make assumptions explicit. Document expected inputs, outputs, ownership, and failure behavior.
- Validate at boundaries. Treat user input, files, messages, and third-party responses as untrusted.
- Design for failure. Decide what happens when dependencies time out, data is malformed, or a process is retried.
- Prefer observable behavior. Log meaningful outcomes and expose enough diagnostics to debug without leaking secrets.
- Test the invariant. A test should prove a property that must remain true, not merely repeat the implementation.
Practical assignment
Draft a CI checklist for a frontend and API repository. Decide which checks run on pull requests and which steps are allowed only on the main branch.
Suggested solution and reasoning
Pull requests run install-from-lockfile, lint, typecheck, tests, and build. Main-branch deployment uses protected environment secrets, deploys an immutable artifact, performs a smoke test, and documents rollback.
Use this as a reference design, not the only possible answer. A strong submission states assumptions, includes failure cases, and demonstrates how correctness will be tested.
Knowledge check
- What problem does this design solve, and what simpler alternative did you consider?
- Which input or dependency is most likely to fail?
- What invariant must remain true after a retry?
- How would you test the unhappy path?
Completion checklist
- I can explain the concepts without reading the lesson.
- I completed the practical assignment.
- I tested at least one failure scenario.
- I documented trade-offs and next steps.