FE9: End-to-end tests and shipping safely
CI pipelines and preview deployments
🎯You'll be able to
Run tests in a CI pipeline and review changes on preview deployments.
🏠The everyday picture
A factory line has checkpoints: each station checks its part before passing it on, and a faulty item is pulled off the line before packing. A CI pipeline does the same for every code change.
📘What it really is
- Continuous integration (CI) runs checks automatically on every pull request, for example with GitHub Actions:
- install dependencies (cached, for speed);
- lint and format check (FE7);
- type check;
- unit and component tests (FE8);
- build;
- E2E tests against the build or a preview;
-
performance and size budgets (FE4–FE5), such as a Lighthouse check or bundle size limit.
-
Branch protection: the main branch accepts changes only through pull requests with passing checks and a review.
-
Preview deployments: hosts such as Vercel and Netlify build each pull request at its own URL. Reviewers, designers and product owners can try the change on their phones before it merges.
-
Keep the pipeline fast (aim for under 10 minutes): run in parallel, cache, and run the slowest E2E tests only where needed.
- Fail clearly: each step's output should say what broke and where.
📝A worked example
Kirana's pull request pipeline:
| Step | Time | Blocks merge? |
|---|---|---|
| Lint, format, type check | 40 s | Yes |
| Unit and component tests | 70 s | Yes |
| Build, with bundle size budget (170 KB for product page) | 60 s | Yes |
| E2E: 5 journeys against the preview | 3 min | Yes |
| Lighthouse on product page (mobile) | 1 min | Warning only below target |
| Preview URL posted on the pull request | — | — |
A pull request that accidentally imported the whole icon set failed the size budget and was fixed before review.
🌍Where it's used
- Every team codebase on GitHub, GitLab or similar.
- Design and product review through preview links.
- Open-source projects checking outside contributions.
📝Case scenario
A team merges straight to main and deploys by hand. A Friday change breaks checkout on Safari, and nobody notices until Monday. You set up branch protection, a CI pipeline with E2E tests on WebKit, and preview deployments. The next Safari bug is caught on its pull request, before it reaches anyone.
🖱️Try it
Write a GitHub Actions workflow for your Kirana project that runs lint, type check, tests and build on every pull request. Connect a host for preview deployments, open a pull request, and check that the preview URL appears.
⚠️Common mistakes
- Running tests only on your machine. Sign: 'it worked for me'. Fix: run them in CI on every pull request.
- Merging with a red check. Sign: a broken main branch. Fix: block merging until checks pass.
🛠️For your project
For the capstone, run the kit's tests in a pipeline or record a full local run; either is acceptable evidence.
✅Quick check
What is a preview deployment?
Show the answer
A temporary live copy of the app built from a pull request, so people can try the change before it merges.
Why keep the CI pipeline fast?
Show the answer
Slow pipelines delay every change and tempt people to skip or bypass them.