3. CI/CD核心概念

在软件工程中,CI/CD 是一条从“代码提交”到“价值上线”的自动化流水线。它由三个既相互衔接又边界清晰的概念组成:持续集成(Continuous Integration,CI)、持续交付(Continuous Delivery,CD)和持续部署(Continuous Deployment,CD)。很多初学者把三者混为一谈,实际上它们回答的是三个不同的问题:代码是否始终能合到一起?合到一起的产物是否始终可发布?可发布的产物是否自动上线?

一句话区分:CI 保证“集成不破”,持续交付保证“随时能发”,持续部署保证“自动就发”。三者是能力递进关系,而不是同义词。

一、核心定义与原理

持续集成指开发者频繁地把代码合并到主干,每次合并都触发自动构建与自动化测试,尽早暴露集成错误。它的核心不是“频繁提交”这个动作,而是“每次提交都验证”的反馈闭环。关键实践包括:单一主干、小步提交、自动化构建、自动化测试、快速反馈。

持续交付是在 CI 的基础上,保证主干上的每一次通过验证的变更都处于“可随时发布到生产”的状态。它要求构建产物可追溯、部署过程可重复、环境配置可版本化,并且发布动作通常只需一次人工确认。持续交付并不强制自动上线,它强调的是发布能力而非发布行为。

持续部署则把持续交付中最后那道人工确认也去掉:只要变更通过全部质量门禁,就自动发布到生产环境。它要求极高的自动化测试覆盖率、完善的可观测性、灰度与回滚机制,否则风险会直接传导到现场。

二、三者的关系与差异

下图展示了从代码提交到生产上线的完整链路,以及 CI、持续交付、持续部署各自覆盖的边界。可以看到,三者共享同一条流水线,区别在于“自动化停止在哪一步”。

CI / 持续交付 / 持续部署 的流水线边界 代码提交 Git Push / MR 自动构建 编译 / 打包 自动化测试 单元 / 集成 / 静态检查 可发布产物 版本化 / 可追溯 生产环境 上线运行 持续集成 CI:提交即构建 + 测试,保证主干始终可集成 持续交付:产物始终可发布,上线需一次人工确认 持续部署:通过门禁即自动上线 自动化程度递增 → 人工干预递减 → 对测试与回滚能力要求递增

用表格可以更清晰地对比三者的关键差异:

维度 持续集成 CI 持续交付 持续部署
核心目标 集成不破、快速反馈 随时可发布 自动上线
触发方式 每次代码提交 CI 通过后 质量门禁全通过
是否自动上线 否 否(人工确认) 是
关键依赖 构建、单元测试 部署自动化、环境一致性 灰度、监控、自动回滚
主要收益 减少集成冲突 缩短发布周期 极速交付、减少人工
主要风险 测试不足导致假绿 环境漂移 缺陷直达现场

三、在工业自动化中的适用性

PLC 项目与互联网软件有本质差异:程序运行在真实设备上,一次错误可能导致停线、设备损坏甚至人身风险。因此,CI/CD 在工业自动化中需要“分层落地”。

  • CI 高度适用:PLC 代码(如结构化文本 ST、梯形图导出的 XML、SCL 源文件)完全可以纳入 Git,每次提交触发语法检查、变量表校验、库版本比对和逻辑单元测试,提前发现变量重复、地址冲突、块缺失等问题。
  • 持续交付适用但需谨慎:可以把编译产物、硬件组态、HMI 画面打包成可追溯的发布版本,但“上线”通常意味着下载到现场 PLC,必须保留人工确认与停机窗口。
  • 持续部署仅限特定场景:在仿真环境、测试台架、数字孪生或非安全相关的辅助系统上,可以尝试自动部署;涉及安全联锁、运动控制、过程安全的部分,不建议全自动上线。

工业场景的推荐路径:先把 CI 做扎实(自动构建 + 静态检查 + 逻辑测试),再实现持续交付(版本化产物 + 一键部署到测试台架),最后在低风险回路中试点持续部署。不要跳过 CI 直接追求自动上线。

四、案例与常见误区

某汽车零部件产线使用 TIA Portal 开发 PLC 程序,团队最初采用“各自改、周末合并”的方式,经常出现变量表冲突和块覆盖。引入 CI 后,每次推送自动执行以下检查:

# 伪代码:PLC 项目 CI 流水线关键步骤
1. git checkout main
2. 导出 PLC 源文件(SCL/ST/XML)
3. 运行语法与变量表校验
4. 执行逻辑单元测试(仿真环境)
5. 生成带版本号的发布包
6. 归档产物并通知负责人

# 若任一步失败,流水线立即红灯并阻断合并

引入后,集成冲突从每周数次降到接近零,发布前的回归时间从两天缩短到两小时。但团队也踩过坑:一开始只做“能编译”,没有逻辑测试,结果出现“编译通过但逻辑错误”的假绿;后来补充了仿真测试用例才真正发挥价值。

三个常见误区:①把“装了 Jenkins”当成做了 CI,实际没有自动化测试;②把持续交付等同于持续部署,忽略了人工确认的价值;③在安全相关回路盲目自动部署,缺少回滚与灰度机制。CI/CD 的本质是用自动化换取反馈速度与发布信心,而不是追求“无人化”本身。

复盘来看,工业自动化落地 CI/CD 的关键不是工具,而是三件事:代码可版本化、构建可重复、验证可自动化。只要这三点成立,CI 就能带来立竿见影的收益;持续交付和持续部署则应根据现场风险等级逐步推进,做到“能力先行、风险可控”。