CI（Continuous Integration，持续集成）指开发者把代码改动频繁合并到共享主干，每次合并自动触发构建和测试校验，以便尽早发现集成问题、让主干保持可交付状态。本文从定义、范围边界、运行环节和相邻概念几个角度说明CI是什么，并澄清常见误解。
要点总览（TL;DR）
- CI（持续集成）是一种研发协作实践：开发者频繁把代码改动合并到共享主干，每次合并自动触发构建与测试校验，尽早暴露集成问题。
- 判断一项做法是否属于CI，看它是否直接服务于频繁合并、自动校验、快速反馈这条主线；流水线工具安装、发布部署决策不在CI范围内。
- 一次CI运行通常包括提交触发、代码拉取与依赖准备、编译构建、自动化测试分层、结果反馈与失败处置、主干状态维护六个环节。
- CI与持续交付、持续部署是包含关系，区别在于自动化延伸到哪一步；与每日构建的区别集中在反馈周期，CI以分钟计，每日构建以天计。
- CI不等于装一个工具或只做自动化测试，合并频率与失败即修的协作约定才是CI成立的关键。
CI持续集成的准确定义
CI的中文全称是持续集成，英文全称是Continuous Integration。可以这样表述：CI是一种研发协作实践，要求开发者把代码改动频繁合并到共享主干，每次合并都自动触发构建、测试等校验，目标是尽早暴露集成问题，让主干保持在可交付状态。
这个定义里有四个关键词，分别对应CI的四个支点：
- 频繁合并到共享主干：开发者在小批量改动完成后就合入主干，缩短分支与主干的分叉时间。合并频率是CI成立的前提，改动积压越久，合并冲突和隐藏问题越多。
- 自动触发：校验由代码提交或合并事件自动启动，不依赖某个人记得手动执行。自动触发保证每次合并都经过同一套检查，结果可比。
- 构建与测试校验：校验内容包括代码能否编译、依赖能否解析、自动化测试能否通过等。校验范围由团队约定，核心是覆盖那些能判断改动是否破坏主干的检查。
- 尽早发现、保持可交付：CI的价值不在“跑了流水线”，而在问题被发现的时间点前移。主干随时处于可交付状态，后续发布才有稳定的起点。
需要区分的是，CI是一套围绕频繁合并与自动校验建立的约定和流程；流水线工具的安装配置属于工具链集成范畴，是承载CI的手段，而非CI本身。
CI包括什么、不包括什么
判断一项做法是否属于CI，可以看它是否直接服务于“频繁合并、自动校验、快速反馈”这条主线。下表按归属给出对照：
| 做法 | 是否属于CI | 说明 |
|---|---|---|
| 提高合并频率，小批量提交 | 属于 | CI的核心动作，决定集成问题的暴露速度 |
| 提交后自动触发构建 | 属于 | 保证每次合并都经过一致的编译校验 |
| 提交后自动运行测试 | 属于 | 用测试结果判断改动是否破坏主干 |
| 构建或测试失败后快速反馈给提交者 | 属于 | 反馈速度直接影响修复成本 |
| 流水线工具的安装与部署配置 | 不属于 | 属于工具链集成与环境配置工作 |
| 编写构建脚本、测试脚本的编程教学 | 不属于 | 属于工程实现技能，不是CI的概念范围 |
| 发布与部署决策，如何时上线、灰度比例 | 不属于 | 属于发布管理，位于CI之后 |
CI与持续交付、持续部署是包含关系：持续交付在CI的基础上，进一步保证代码随时可以发布到生产环境，发布动作仍由人决定；持续部署则把发布也自动化，通过校验的改动自动进入生产。三者共用同一套自动校验基础，区别在于自动化延伸到哪一步。把部署决策算进CI，会让概念边界模糊，也不利于分清各环节的责任。
一次CI运行由哪些环节组成
理解CI的机制，最直接的方式是跟踪一次代码提交之后的完整流程。下面按顺序展开各环节及其产出：
提交触发
开发者把改动推送到共享主干或发起合并请求，触发事件产生。产出是一个明确的待校验版本，以及与之关联的提交记录。触发条件是CI的起点，触发规则需要覆盖所有进入主干的路径。
代码拉取与依赖准备
流水线拉取对应版本的代码，准备构建所需的依赖和运行环境。产出是一个与提交版本一致、可重复构建的工作环境。环境不一致是构建结果不稳定的常见原因，这一步的稳定性决定后续校验是否可信。
编译构建
执行编译、打包等构建动作，产出可运行的构建产物。构建失败通常意味着代码存在语法、依赖或配置层面的问题，应在这一环节立即反馈，不必等到测试阶段。
自动化测试分层
按层次运行测试，常见分层包括单元测试、集成测试，部分团队还会加入接口测试或端到端测试。产出是各层测试的通过率与失败明细。分层的作用是让大部分问题在运行最快的单元测试层被发现，把耗时较长的测试留给更少的场景。
结果反馈与失败处置
构建与测试结果反馈给提交者和相关协作方。失败时的处置约定通常包括：暂停向主干合入新改动、优先修复、必要时回退有问题的提交。产出是一个明确的主干状态判断——通过或阻塞。
主干状态维护
一次运行结束后，主干要么保持可交付，要么被标记为待修复。维护主干状态是CI的收尾动作，也是下一轮合并的起点。主干长期处于失败状态，CI的快速反馈价值就会消失。
CI与相关概念的区分
CI常与几个相邻概念一起出现，它们回答的问题不同，所处位置也不同。下表按同一口径对照：
| 概念 | 回答的问题 | 在交付链条中的位置 |
|---|---|---|
| CI持续集成 | 改动合入主干后是否破坏了构建与测试 | 合并与校验环节 |
| 持续交付 | 当前代码是否随时可以发布 | CI之后，发布之前 |
| 持续部署 | 通过校验的改动能否自动上线 | 交付链条末端 |
| nightly build（每日构建） | 一天积累的改动整体是否可用 | 按固定周期运行，反馈以天计 |
| 代码评审 | 改动在设计与实现上是否合理 | 合并前的人工判断环节 |
| 分支管理 | 改动以什么方式组织与合入 | 为CI提供合并节奏与主干约定 |
| 流水线工具 | 用什么系统执行自动校验 | 承载CI的执行手段 |
CI与nightly build的区别集中在反馈周期：每日构建把一天的改动集中验证，问题可能在提交后数小时甚至次日才暴露，定位范围也更大；CI在每次合并时校验，反馈以分钟计，问题能对应到具体改动。两者可以并存，但每日构建不能替代CI的快速反馈。
CI与代码评审、分支管理是分工关系：评审判断改动该不该合，分支管理决定改动怎么合，CI判断合入后主干是否仍然健康。三者缺一，主干的可交付状态就缺少保障。流水线工具则是执行层，工具可以更换，CI的约定不随工具变化。
在管理动作上，团队需要把提交、构建结果与需求或任务状态对应起来，才能判断某次失败影响哪些交付内容。ONES DevOps 解决方案可集成 Jenkins、GitLab CI 等第三方流水线工具，同步流水线执行状态和日志，并支持通过工作项拉取代码分支、将代码提交与业务工作项关联，在项目、迭代、需求中查看代码提交与流水线构建情况。这类关联解决的是“构建结果对应哪个需求、由谁跟进”的协作问题，CI的校验规则本身仍由团队约定。
一个具体例子与常见误解
以下为演示情景，用于说明CI的运行方式，不代表特定团队的真实数据。
一个五人开发小组维护一个共享主干。某天上午，一名开发者完成一个订单状态校验的小改动，提交并合入主干。提交事件自动触发流水线：系统拉取最新代码、安装依赖、编译构建，构建通过后依次运行单元测试和集成测试。单元测试在几分钟内完成，其中一条用例失败，反馈直接指向这次改动涉及的校验逻辑。开发者收到通知，暂停其他合并，修复后重新提交，流水线再次运行并通过，主干恢复可交付状态。整个过程从提交到确认修复，控制在较短时间内，问题没有流入后续环节。
围绕这个流程，有三种高频误解值得澄清：
- 误解一：CI等于装一个工具。工具安装只是让自动校验具备执行条件。若合并仍然稀疏、失败长期不修，工具在跑，CI的约定并未建立。正确理解是：CI的成立标志是频繁合并与失败即修的协作习惯，工具是承载手段。
- 误解二：CI等于自动化测试。自动化测试是CI校验的重要组成部分，但CI还包括合并频率、构建校验、反馈机制和主干状态维护。只补测试而不改变合并节奏，集成问题仍会积压。
- 误解三：合并越少越安全。合并间隔越长，分支与主干的差异越大，合并时的冲突和隐藏问题越多，定位范围也越难收敛。CI主张小批量、高频率合并，把风险拆散到每次小改动中处理。
这些误解的共同来源，是把CI的某个组成部件当成了全部，或把工具能力当成了协作约定。回到定义判断：一项做法是否算CI，看它是否让改动更频繁地进入主干、是否在每次合并后自动校验、是否让问题在最短时间内被提交者看到并修复。三个条件同时成立，主干的可交付状态才有持续保障。
常见问题
团队合并频率不高，但每次合并都跑自动化测试，这算CI吗？
按定义判断，这种情况只满足了自动校验这一部分。CI还要求改动频繁进入共享主干，让问题在小批量改动中被发现。合并间隔较长时，分支与主干的差异会持续累积，测试通过也只能说明这一次合并没有破坏主干，无法消除长期分叉带来的冲突和隐藏问题。更贴近CI的做法是缩短合并间隔，把改动拆小，让每次合并都经过自动校验。
CI流水线失败后，团队应该先修复还是先继续合并？
常见约定是暂停向主干合入新改动，优先修复导致失败的问题，必要时回退有问题的提交。原因是主干处于失败状态时，后续合并的校验结果会失去参考价值，问题定位范围也会扩大。具体处置方式可以按团队情况约定，例如区分构建失败与测试失败的处理优先级，但主干状态的恢复应当放在继续合并之前。
每日构建和CI能同时存在吗？
可以。两者回答的问题不同：CI在每次合并时校验，反馈以分钟计，问题能对应到具体改动；每日构建把一天积累的改动集中验证，适合运行耗时较长、不适合每次合并都执行的检查。并存时需要注意，每日构建不能替代CI的快速反馈，否则问题仍可能在提交后数小时才暴露，定位范围也更大。
CI的构建结果如何与需求、任务对应起来？
这属于研发协作层面的管理动作。ONES DevOps 解决方案可集成 Jenkins、GitLab CI 等第三方流水线工具，同步流水线执行状态和日志，并支持通过工作项拉取代码分支、将代码提交与业务工作项关联，在项目、迭代、需求中查看代码提交与流水线构建情况。这样团队能判断某次构建失败影响哪些交付内容、由谁跟进。CI的校验规则本身仍由团队约定，工具解决的是结果与工作项的对应关系。
小团队人少、提交不频繁，还需要CI吗？
CI的核心是缩短集成问题的暴露时间，与团队规模没有直接绑定。人少的团队同样会面临分支分叉、合并冲突和改动互相影响的问题，只是问题出现的频率和影响范围不同。是否引入CI，可以看团队是否经常遇到合并后才发现构建失败、测试不通过的情况。若存在这类情况，先建立小批量合并和提交后自动校验的约定，再考虑工具承载，比直接上工具更有效。
