I often hear teams put off CI because setup feels tedious, or they think things are fine as they are. When I join a project for code review, I introduce CI there too without hesitation. Here is a short summary of what I tell them.
The purpose of CI is to reduce developer burden. More precisely, CI lets developers work more easily.
If you treat the code on GitHub shared by the whole team as the source of truth and the code each developer clones locally as a derivative, then before opening a pull request from derivative to source you normally need to confirm, assuming functional requirements are already met:
- Does it build in other environments too? (Is it tied only to your machine? /
build) - Is the code formatted the way the team agreed? (Line length, commas, single quotes, and so on /
prettier) - Does the code follow the TypeScript style the team agreed on? (No
any, no unused declared variables, and so on /es-lint)
For people reviewing pull requests, it is also desirable to have:
- A preview URL for each pull request
- Lighthouse scores for each pull request
Without CI, the person opening a pull request must run all of these checks locally without missing any, and attach the preview URL and Lighthouse results. Reviewers deciding whether to merge into main would then have to verify locally each time that those checks happened. That is unbearable. Depending on the work, it can happen dozens of times a day!
CI exists to eliminate that cost. Every push or pull request to GitHub runs the configured Actions automatically and reports the results, so developers are freed from repeating those checks by hand. Automate what can be automated, and focus on work only humans need to do!
Commonly Used Actions
- build: Does
npm run buildsucceed? This catches simple mistakes and environment-specific dependencies (for example, packages installed globally withnpm i -g) - lint: After configuring team rules with
es-lintandprettier, check for violations with those tools. You can also run this withlint-staged, but CI catches cases where that did not run or was bypassed - test: Run unit tests and e2e tests
- doc: Generate documentation from code. TypeDoc is common
- hosting: Deploy each pull request or the latest
mainbranch to Firebase Hosting so reviewers can check from a URL - lighthouse: Measure audits with lighthouse-ci