---
title: "Continuous integration"
description: "A practice where changes are regularly checked and merged so problems surface early."
category: "AI and tooling"
canonical: "https://contentlexicon.com/continuous-integration"
updated: "2026-10-11"
---

# Continuous integration

_AI and tooling_

> A practice where changes are regularly checked and merged so problems surface early.

Continuous integration is the practice of merging small changes into a shared main version frequently, often several times a day, with automated checks run on every merge. Problems show up while each change is still small enough to understand and fix.

It comes from Extreme Programming, the software method Kent Beck developed in the late 1990s, and Martin Fowler's article Continuous Integration, first published in 2000, spread it more widely. The working rules are short. Everyone integrates their work with the main version at least daily. Each change triggers an automated build and a set of tests. If the build breaks, fixing it comes before any new work, so the main version is always in a usable state.

## Why it matters for content

Content often builds up in documents until a migration or launch, when hundreds of changes meet at once. Frequent integration reveals missing fields, broken links, terminology differences and structural problems earlier, while they're cheap to fix.

A content version runs checks every time someone proposes a change. A prose [linter](https://contentlexicon.com/linting) such as Vale tests the text against the [style guide](https://contentlexicon.com/style-guide), flagging banned terms, inconsistent product names or headings that break the capitalisation rule. Link checkers catch broken internal and external links. Validators confirm that required [metadata](https://contentlexicon.com/metadata) is present and structured data is well formed. Automated [accessibility](https://contentlexicon.com/accessibility) tests catch specified failures, such as missing [alt text](https://contentlexicon.com/alt-text) or skipped heading levels, though they can't establish that the whole experience is accessible. Docs-as-code teams usually run these checks on each [pull request](https://contentlexicon.com/pull-request), so the [writer](https://contentlexicon.com/writer) sees the results before a reviewer does.

The same rule about broken builds applies. If the checks fail on the main version, someone fixes that before publishing anything else.

Continuous integration depends on a shared source and version history. Publishing more often isn't the same thing; changes have to be combined and checked in a reliable process. Review also needs to cover meaning, evidence and how people use the result.

## How AI changes the picture

[Prompts](https://contentlexicon.com/prompt), knowledge sources and evaluation cases can enter the same process. A team could test whether a changed eligibility rule still produces the right explanation for a set of sample questions. These tests check selected behaviour. They can't predict every future answer.

AI can help write tests and explain failures, but generated checks need review. A system can pass every formal rule while producing an unhelpful answer.

Small, visible changes make AI behaviour easier to trace than occasional wholesale prompt rewrites.

## Questions people ask

**Is continuous integration the same as continuous delivery?**

No. Integration combines and checks changes. Continuous delivery keeps successful changes ready for release, and continuous deployment goes further by releasing them automatically after the required checks.

**Must content be stored in Git?**

No, though the system needs version history, a shared source and a way to run checks on each change.

**What content checks can be automated?**

Style rules, terminology, links, required fields, formats, some accessibility patterns and some consistency checks are good candidates. Start with a few rules and add more as the team trusts them.

**Does automation remove editorial review?**

It can reduce routine checking. Someone still needs to decide whether the checks are appropriate and review what they don't cover.

## Learn more

- [Continuous Integration](https://www.martinfowler.com/articles/continuousIntegration.html) – Martin Fowler's detailed account of frequent integration, automated builds and repairing failures; a software practice to adapt thoughtfully to content.
- [Continuous documentation deployment](https://docs.readthedocs.com/platform/stable/continuous-deployment.html) – a concrete example of documentation entering the same build, review and release rhythm as software.
- [How to introduce prose linters at your workplace](https://passo.uno/prose-linters-implement-workplace-howto/) – Fabrizio Ferri-Benedetti's practical advice on bringing a style linter such as Vale into a writing team, including adding rules to the pipeline gradually.

Related terms: [Automated testing](https://contentlexicon.com/automated-testing), [Content health check](https://contentlexicon.com/content-health-check), [Content maintenance](https://contentlexicon.com/content-maintenance), [Devops](https://contentlexicon.com/devops), [Linting](https://contentlexicon.com/linting)

This page was last reviewed in October 2026.