Continuous integration (CI) is the practice of building and testing each commit in the repository. It is done automatically by machines and can be integrated with GitHub to display the status of each commit.
Cornell DTI uses GitHub Actions as our CI service.
Each active project must contain a CI configuration that checks the following:
- Code Style
- Linter Errors
- Your project can build/compile
All CI checks must pass before your branch can be merged into
Here is an example CI workflow:
Continuous deployment (CD) is a practice that deploys each good commit (after passing) CI to staging servers.
- For heroku projects, we configure heroku to autodeploy master branch to staging.
- For Firebase projects, we use GitHub Actions to auto deploy the app to Firebase Hosting.
- Bad code cannot be merged into master
- All code must be committed to a separate branch before merging.
- All code must pass CI checks before merging.
- All code must pass code review before merging.
- Giant pull requests are prohibited.
- big-diff-warning will automatically invite developer lead to review giant pull requests.
- Unless there is a convincing reason for big pull requests, there will be rejected.
- Timely feedback of pull requests
- We use GitHub scheduled reminders to periodically list open pull requests without review in our slack channels.
- Website/App Status Checks
- dti-repo-tools performs health check for every project with public website every ten minutes.