Continuous Intergration

Continuous integration (CI) automatically builds your codes,runs tests on a variety of different platforms, and deploys all manner of builds and documentation as desired Typically this may be run when new code is proposed (e.g. through GitHub Pull Requests), or committed to the  repository. CI is useful for catching bugs before they reach your end users, and for testing on platforms that are not available to every developer.

CI can be broken down into several stages. Most CI should at least build the code and then run unit tests. The build stage takes the source code and does any compilation and dependency resolution/installation for the next stage. Compiled languages like C++ and Rust require this step to turn all the source code into executables. Interpreted languages like Python or R do not usually need this step explicitly to turn source code into compiled code, but still typically need to install dependencies. The unit test stage runs a series of tests to ensure the code is working as expected without syntactical or logical errors. Most, if not all, codes should have these. Some codes where accuracy is needed (especially in the scientific field) should also include a regression test stage where accuracy is compared against computed values. Regression tests can take significantly longer than unit tests and may need to be relegated to very infrequent CI runs, or handled through a separate means. Lastly a deploy stage can take any compiled and verified code and push it to the appropriate branch or service to make it available. Deployment can also include things such as documentation pages, API’s, and experimental/nightly builds.

GitHub itself now provides a CI service for its repositories called “GitHub Actions” which can be configured to run with most repos. However, there are also many other CI services, most of which have webhooks for integration with GitHub. There are also CI services for non-GitHub based code repositories.

Examples of CI Software/Services