Written and maintained by CASRAI Editorial Board
Last updated
Continuous integration (CI) is a software practice that requires frequently committing code to a shared repository, with an automated build and test run each time. For research teams, its practical value is narrower and more useful than the usual “ship faster” pitch: CI re-runs your tests on a separate machine after every change, so a result is never silently produced by code that no longer works.
What continuous integration is
GitHub’s documentation defines continuous integration as “a software practice that requires frequently committing code to a shared repository.” Martin Fowler’s widely cited article gives the stricter, team-level version: each member of a team merges their changes into a codebase together with their colleagues’ changes at least daily. The Turing Way, the community handbook for reproducible research, describes it as the practice of integrating changes made by individuals into a main, shared version frequently, usually multiple times per day.
The three descriptions agree on the core: small, frequent merges into one shared line of work, with software checking each merge. The Turing Way adds that CI software is also typically used to identify conflicts and bugs introduced by changes. Because the check runs automatically, nobody has to remember to run the tests.
CI is not the same as “CI/CD”. GitLab’s documentation describes CI/CD as “a continuous method of software development” and notes that it can catch bugs early in the development cycle; the “CD” half (continuous delivery or deployment) is about releasing the result, and is a separate step from the integration practice described here.
What it is used for in research
The Turing Way lists the benefit that matters most for analysis code: CI helps bugs to be found early, minimising their damage and making them easier to fix. It also warns of the wasted effort that follows when results are produced using faulty code. A paper’s figures, a simulation, or a data-cleaning pipeline are all code that can break quietly when a colleague changes a shared function or a dependency updates.
Two further points from the same source shape how research groups should set it up:
- Continuous integration runs every time a new commit is made to your project, so every change gets the same check, not only the ones someone thought were risky.
- It runs your tests on a separate computer, usually in the cloud. That machine starts without your local setup, so the software environment has to be described well enough to be recreated. This is why CI and reproducibility practices reinforce each other: a project whose tests pass on the CI machine has shown that its environment can be rebuilt from its own instructions.
CI needs somewhere to watch for changes, which means a version-controlled code repository. If your group is still deciding what that looks like, the software engineering overview places automated testing and continuous integration among the core practices.
How a CI run works
- A change is pushed. Someone commits to the shared repository, usually through a branch and a pull request.
- A trigger fires. On GitHub, workflows can be started by a GitHub event, on a schedule, or by an external event through the repository dispatch webhook.
- The work runs on a separate machine. GitHub states that workflows can run on GitHub-hosted virtual machines, or on machines that you host yourself. In GitLab, a runner executes the jobs.
- The result is reported. GitHub runs your CI tests and provides the results of each test in the pull request. When all CI tests in a workflow pass, the changes you pushed are ready to be reviewed by a team member or merged.
GitHub also offers CI workflow templates for a variety of languages and frameworks, and can suggest templates by analysing your repository, so a first configuration rarely starts from a blank file. For a hands-on first workflow, follow the GitHub tutorials for beginners rather than copying configuration from a summary page.
Practices that make it real
Having a CI server is not the same as doing continuous integration. Fowler’s article lists the practices that separate the two. They are useful as a self-audit for a research group:
- Put everything in a version controlled mainline
- Automate the build
- Make the build self-testing
- Everyone pushes commits to the mainline every day
- Every push to mainline should trigger a build
- Fix broken builds immediately
- Keep the build fast
- Hide work-in-progress
- Test in a clone of the production environment
- Everyone can see what’s happening
- Automate deployment
For an analysis project, “make the build self-testing” is the one most often missing: a build that only installs dependencies proves little. “Test in a clone of the production environment” maps directly onto the reproducible-environment point above. “Automate deployment” is the last item and is optional for projects that never deploy anything.
GitHub Actions and GitLab CI/CD compared
The two most common hosted options describe the same ideas in different vocabulary. Each row below is taken from the platforms’ own documentation. For a wider comparison of the platforms themselves, see Git vs GitHub vs GitLab.
| Aspect | GitHub (Actions) | GitLab (CI/CD) |
|---|---|---|
| Where the pipeline is defined | Workflows; templates are offered for many languages and frameworks | A .gitlab-ci.yml file at the root of your project |
| Structure | Workflows triggered by a GitHub event, a schedule, or an external event via the repository dispatch webhook | A pipeline of stages and jobs; stages define the order of execution and jobs specify the tasks in each stage |
| Where it runs | GitHub-hosted virtual machines, or machines you host yourself | A runner executes the jobs |
Reading the output and fixing a failing build
On GitHub the results of each test appear in the pull request, and a change is ready for review or merge once all CI tests in the workflow pass. Fowler’s practice “fix broken builds immediately” is the rule that keeps this useful: if a red build is left alone, the team stops trusting the signal and the check stops protecting anyone. Treat a failing run as the first task, not as noise to merge around.
Frequently asked questions
What is continuous integration in simple terms?
It is the practice of frequently merging code changes into one shared repository and having software automatically check each change, so problems are found while they are small.
How often should changes be integrated?
Fowler’s definition says each team member merges at least daily; the Turing Way describes integration as frequent, usually multiple times per day.
Why does a research project need CI?
The Turing Way points to finding bugs early and avoiding wasted effort when results are produced using faulty code. Running tests on a separate machine on every commit also checks that the project’s environment can be recreated.
Is CI the same as CI/CD?
No. CI is the integration-and-check practice; CI/CD additionally covers continuous delivery or deployment. GitLab’s CI/CD documentation covers both together.
Sources
- GitHub Docs, Continuous integration: docs.github.com/en/actions/get-started/continuous-integration (checked 2026-10-29)
- Martin Fowler, Continuous Integration: martinfowler.com/articles/continuousIntegration.html (checked 2026-10-29)
- GitLab Docs, CI/CD: docs.gitlab.com/ci/ (checked 2026-10-29)
- The Turing Way, Continuous Integration: book.the-turing-way.org/reproducible-research/ci (checked 2026-10-29)
