What is Continuous Integration?

Continuous Integration, usually shortened to CI, is a software development practice in which developers integrate code changes into a shared codebase frequently and use an automated build and test process to detect problems quickly. The important idea is not simply that a CI tool runs tests. It is that changes are integrated regularly into a common mainline and each integration is verified so the shared codebase stays healthy.

CI reduces the size and uncertainty of each integration. Instead of allowing branches and incompatible changes to diverge for long periods, teams integrate small changes frequently, receive rapid feedback and fix failures while the relevant change is still fresh.

The infographic below shows the core CI workflow, where CI fits into CI/CD, common tools and the practical benefits.

How does Continuous Integration work?

A CI workflow starts with version control. Developers work on small changes, synchronise with the shared codebase and integrate those changes frequently. A CI service observes the repository and runs a defined workflow whenever the configured trigger occurs, commonly a push or pull request.

1. A developer makes a small code change and updates or adds tests where appropriate.

2. The change is committed and pushed to the version controlled repository.

3. The CI service checks out the relevant revision in a clean or controlled runner environment.

4. Dependencies are installed and the software is built or packaged.

5. Automated checks run, which can include unit tests, integration tests, linting, type checks, security checks and code coverage rules.

6. The CI service reports a pass or failure to the developer and team.

7. A failed build is investigated and corrected before the broken state is allowed to persist.

GitHub describes CI as frequently committing code to a shared repository and continuously building and testing it so errors can be detected sooner. Its CI workflows can run on hosted or self hosted runners. See GitHub's Continuous Integration documentation.

Continuous Integration is a practice, not just a tool

Installing Jenkins, GitHub Actions or another automation service does not automatically mean a team is practising Continuous Integration. The deeper practice is frequent integration into a shared mainline backed by a reproducible automated build and meaningful automated tests.

Martin Fowler's updated Continuous Integration guidance describes team members merging their changes with colleagues' changes at least daily, with each integration verified by an automated build that includes testing. See Martin Fowler's Continuous Integration guide.

What happens inside a CI pipeline?

• Checkout: retrieve the exact source revision that triggered the workflow.

• Dependency setup: install or restore the required libraries, packages and toolchains.

• Build: compile, bundle or otherwise turn source into the required build output.

• Static checks: run linters, format checks, type checks or other analysis.

• Automated tests: execute the test suites selected for the CI stage.

• Security checks: optionally scan dependencies, code or artefacts for known issues.

• Artefact creation: produce versioned packages, binaries or container images where required.

• Status reporting: return pass or fail information to the repository and development team.

The exact stages vary by project. A static website may have a very small pipeline, while a large application can have parallel test suites across multiple operating systems, language versions or architectures.

Continuous Integration vs Continuous Delivery vs Continuous Deployment

CI, Continuous Delivery and Continuous Deployment describe different parts or levels of software delivery automation. They are often grouped under the label CI/CD, but they should not be treated as interchangeable.

• Continuous Integration: integrate code frequently and automatically build and test each integration.

• Continuous Delivery: keep software in a releasable state so a production release can be performed reliably when authorised.

• Continuous Deployment: automatically deploy qualifying changes to production after the required automated checks pass, without a routine manual production release step.

A CI pipeline can finish with a tested artefact and never deploy anything. Deployment is a separate process. Techie Broadband explains that distinction in What is Deployment?.

What is the mainline in Continuous Integration?

The mainline is the shared branch that represents the current integrated state of the product. In Git based workflows it is often named main, although naming conventions vary. Frequent integration means developers do not allow their work to remain isolated from the shared codebase for long periods.

Feature branches can still be used with automated checks, but running CI jobs against an isolated branch is not by itself full integration with everybody else's current work. The integration is complete when the change coexists successfully with the shared mainline.

Why automated testing matters to CI

A successful compilation only proves that the build reached that point successfully. It does not prove the software behaves correctly. Automated tests give the CI process a repeatable way to check expected behaviour whenever the code changes.

• Unit tests can check small pieces of logic quickly.

• Integration tests can check whether components work together.

• Functional or end to end tests can exercise user facing behaviour.

• Linters and type checks can detect classes of problems before runtime.

• Security and dependency checks can add another layer of automated feedback.

Tests do not prove that software has no bugs. They reduce uncertainty by checking known expectations consistently and quickly. A weak test suite can produce a green CI result while important defects remain undetected.

What are the benefits of Continuous Integration?

• Smaller integration changes are easier to understand and debug than large batches.

• Merge and compatibility problems are exposed sooner.

• Developers receive rapid feedback while the change is still fresh.

• The shared codebase is continuously checked against a repeatable build process.

• Automation reduces reliance on repetitive manual build and test steps.

• A healthy CI process creates a stronger foundation for Continuous Delivery and Continuous Deployment.

CI does not make bad code good automatically. Its value depends on integration frequency, build reproducibility, test quality, feedback speed and the team's willingness to fix failures quickly.

Common Continuous Integration tools

Many services can automate CI workflows. The choice of tool is less important than whether the workflow actually supports frequent integration and reliable feedback.

• GitHub Actions: repository integrated workflows that can build and test code on GitHub hosted or self hosted runners.

• GitLab CI/CD: pipeline automation integrated with GitLab projects.

• Jenkins: a widely used open source automation server with a large plugin ecosystem.

• Azure Pipelines: build and test automation within Azure DevOps.

• CircleCI: hosted CI/CD automation with configurable execution environments.

A team can also build its own automation. Continuous Integration is defined by the development practice and verification process, not by a specific commercial product.

CI runners and build environments

The runner is the machine or execution environment that performs the CI job. It might be a hosted virtual machine supplied by the CI platform, a self hosted server, a virtual machine, or a container based environment.

Using isolated and reproducible environments helps reduce the problem where software works on one developer's computer but fails elsewhere. CI workloads can themselves run on virtual machines or use containers and Docker to package build environments and services.

Continuous Integration and broadband

CI can be performed entirely within a local network, but cloud hosted repositories and runners make broadband performance relevant. Developers upload commits, runners download source and dependencies, and pipelines may push or pull build artefacts and container images. Upload speed, download speed, latency and the performance of the remote service can therefore affect pipeline time.

The network is only one part of CI performance. CPU, memory, storage, dependency caching, test design, parallelism and queue time can dominate a pipeline even on a very fast broadband connection.

Techie Broadband calculation: transferring a 1 GB CI artefact

Consider a theoretical 1 GB decimal build artefact that must be uploaded from a self hosted CI runner to a remote artefact store. One gigabyte equals 8 gigabits, or 8,000 megabits.

• At 20 Mbps upload: 8,000 Mb ÷ 20 Mb/s = 400 seconds, or 6 minutes 40 seconds.

• At 100 Mbps upload: 8,000 Mb ÷ 100 Mb/s = 80 seconds, or 1 minute 20 seconds.

• At 500 Mbps upload: 8,000 Mb ÷ 500 Mb/s = 16 seconds.

• At 1 Gbps upload: 8 Gb ÷ 1 Gb/s = 8 seconds.

These are theoretical transfer times. Real CI transfers can take longer because of protocol overhead, encryption, latency, storage performance, service limits, contention and other traffic. Caching or incremental uploads can also mean the pipeline transfers much less than the full nominal artefact size.

Why fast feedback matters

A CI pipeline that takes a very long time weakens the feedback loop. Developers may move on to other work before a failure arrives, while queued builds can delay the team's understanding of the mainline state. Fast feedback does not mean every possible test must finish in seconds. It means the workflow should be designed so the most valuable failure signals arrive as early as practical.

• Run fast deterministic checks early.

• Cache dependencies safely where it saves meaningful time.

• Parallelise independent test groups when the infrastructure supports it.

• Avoid rebuilding unchanged work unnecessarily.

• Separate slower specialist checks when doing so does not weaken the required integration gate.

• Investigate flaky tests rather than normalising repeated reruns.

Common Continuous Integration problems

• Broken builds are ignored, so the mainline remains unhealthy.

• Tests are too weak and important regressions pass unnoticed.

• Tests are flaky, so developers stop trusting failures.

• Pipelines take so long that feedback arrives too late.

• Developers integrate infrequently despite having a CI server.

• Builds depend on undocumented software or configuration from one machine.

• Secrets are exposed in repository files, scripts or build logs.

• Dependencies are downloaded from unreliable or untrusted sources.

• Different branches or environments use inconsistent build logic.

• Large artefacts or uncached dependencies create avoidable network transfer.

How to troubleshoot a failing CI pipeline

1. Identify the first failed stage rather than focusing only on the final failed status.

2. Read the actual build or test error and determine whether the failure is compilation, dependency, test, configuration, network or infrastructure related.

3. Reproduce the failing command locally or in an equivalent clean environment where practical.

4. Confirm the CI runner is using the expected source revision, branch, runtime and dependency versions.

5. Check whether required secrets, environment variables and permissions are available to that job.

6. Check network, DNS, package registry and artefact repository access if dependencies or images cannot be retrieved.

7. Compare a failing runner with a known working runner for operating system, architecture, runtime and toolchain differences.

8. Treat intermittent tests as defects in the test or system rather than simply rerunning until green.

9. Fix the underlying issue, rerun the required checks and confirm the shared branch returns to a healthy state.

10. Record recurring failure causes and automate a preventative check where possible.

CI security considerations

CI systems often have access to source code, credentials, package registries and deployment systems, so a compromised pipeline can have significant impact. Access should follow least privilege, secrets should be protected, third party actions or plugins should be reviewed, and build artefacts should be traceable to their source revision.

Self hosted runners need particular care because they execute workflow code on infrastructure controlled by the organisation. The appropriate isolation and trust model depends on who can submit code and what the runner can access.

Continuous Integration FAQs

Does CI automatically deploy software?

No. CI normally builds and tests integrated changes. A separate delivery or deployment stage can use the resulting artefact, but deployment is not required for a process to be Continuous Integration.

Is GitHub Actions the same as Continuous Integration?

No. GitHub Actions is an automation platform that can implement CI workflows. Continuous Integration is the development practice the workflow supports.

Do developers have to commit every day?

The core principle is frequent integration. Martin Fowler describes at least daily integration as a baseline, with experienced CI teams often integrating more frequently. The practical objective is to keep changes small and prevent long lived divergence.

Can CI work with feature branches?

Automated checks can run on feature branches, but a branch is not fully integrated with colleagues' work until its changes are combined with the shared mainline. Long lived branches work against the frequent integration principle.

Does faster broadband make CI faster?

It can reduce time spent transferring source, dependencies, images and artefacts, especially for self hosted runners, but it does not speed up CPU bound compilation, slow tests, queue time or remote service processing.

Key takeaway

Continuous Integration is the practice of integrating small code changes into a shared codebase frequently and verifying those integrations with an automated build and meaningful tests. The goal is rapid feedback and a healthy shared mainline, not simply owning a CI tool. Good CI combines frequent integration, reproducible builds, trustworthy tests, fast feedback and prompt repair of failures.

To explore the related technical concepts used in this Continuous Integration guide, visit our broadband terminology guide.