This category evaluates checks whether your project uses Continuous Integration (CI) and how you are using it.
Continuous Integration is the practice of automating the integration (merging) of all changes that multiple developers make to a software project.
This is done by running an automated process for every commit to your project’s Git repository.
This process then downloads your project’s source code at that commit, builds it, runs the linters configured for the project—we hope you include mllint—and runs the project’s tests against the system.
The core idea is that the CI server should be the unbiased arbiter of whether the project’s code works after a certain set of changes, while providing a standardised environment to your whole team for verifying that the project truly works as intended. No more ‘but it worked on my machine’ excuses.
Explore these sources to learn more about what CI entails:
- WikiPedia - Continuous Integration
- ThoughtWorks, though a sales pitch, succinctly describes CI and several best practices relating to it, as well as its primary advantages.
- SE4ML Best Practice - Use Continuous Integration
To learn how to implement CI, see also the description of rule ci/use
Note: that this category is not fully implemented yet. It may later be expanded with rules on the structure of your CI pipelines (e.g. has stages build, test, deploy, that actually build, test and deploy the project.