Evolution of Continuous Integration: From Basic CI to Enterprise Pipeline Solutions

Continuous integration (CI) is one of the twelve practices of extreme programming, introduced in 1999, aiming to ensure that new code changes do not break the whole software.

The article recounts the author’s experience since 2009, when the term “deployment pipeline” (originally called “管道式持续集成”) was first introduced, and describes how a simple CI setup evolves through several stages.

First, a basic CI pipeline runs a linear sequence of tasks (CheckStyle → Compile → UnitTest → FunctionTest → Report) as shown in an Ant build file:

<project name="Cruise" default="all" basedir=".">
    <target name="all" depends="checkStyle, Compile, UnitTest,FunctionTest, Report"/>
    <target name="checkStyle"> ... </target>
    <target name="Compile"> ... </target>
    <target name="UnitTest" depends="Compile"> ... </target>
    <target name="FunctionTest" depends="Compile"> ... </target>
    <target name="Report" depends="FunctionTest"> ... </target>
</project>

Next, “stage‑based CI” introduces parallel build plans (unit, functional, performance tests) that run on separate agents, balancing feedback speed against test thoroughness.

“Process‑oriented CI” further decomposes the pipeline into independent units (CheckStyle, compile, package, deploy, performance test) to eliminate duplicated work, but adds management complexity.

The final “pipeline‑style CI” merges the advantages of the previous approaches: all stages execute within a single pipeline context, sharing the same code baseline, and the system automatically distributes jobs across multiple agents.

An example Cruise pipeline definition illustrates this model:

<pipeline name="Cruise">
    <stage name="UnitTest">
        <job name="windows-01"/>
        <job name="windows-02"/>
        ...
    </stage>
    <stage name="FuncTest">
        <job name="windows"/>
        <job name="linux"/>
    </stage>
    ...
</pipeline>

By scaling agents and using a load‑balancing tool, the team reduced unit test time to under 15 minutes and functional tests to about 35 minutes, demonstrating how CI can be continuously refined to meet feedback‑time and quality‑accuracy goals.

The article concludes that CI is an iterative practice that requires regular retrospectives, refactoring, and adaptation to team size and project complexity.