1. 课程导入
在传统PLC工程项目中，程序往往由工程师在本地编程软件中编写、下载、调试，最后以压缩包或U盘方式交付。这种方式在单机、小规模项目中尚可运转，但当项目涉及多站点、多版本、多工程师协作时，问题会迅速暴露：谁改动了哪一段逻辑、现场运行的是哪个版本、修改后是否经过验证、出现故障如何快速回退，往往缺乏可追溯的工程化手段。CI（Continuous Integration，持续集成）正是把软件工程中成熟的自动化构建、自动化测试、版本追溯和快速反馈机制，引入到PLC程序开发与交付流程中，使控制逻辑像现代软件一样可管理、可验证、可复现。
一、学习目标：从“能写程序”到“能管程序”
本课程不是再讲一遍梯形图指令或PID整定，而是围绕“工程化”三个字展开。学习完成后，学员应达到以下目标：
- 理解CI/CD的基本理念，并能说明它与PLC传统开发流程的差异与衔接点。
- 掌握PLC项目源码的版本管理方法，包括程序块、硬件组态、变量表、库文件的统一纳管。
- 能够使用脚本或工具链实现PLC程序的自动导出、自动编译与语法检查。
- 能够设计并执行静态检查规则，例如命名规范、未使用变量、重复线圈、危险跳转等。
- 能够搭建基于仿真或软PLC的自动化测试环节，对关键逻辑进行回归验证。
- 能够将构建产物、测试报告、版本信息自动归档，并形成可追溯的交付记录。
- 能够识别CI在工业现场落地时的边界与风险，合理设计人工确认与自动执行的边界。
二、核心价值：为什么PLC程序需要CI
CI对PLC工程的价值，不是“为了自动化而自动化”，而是解决真实工程痛点。其核心价值可以归纳为四个维度：
| 维度 | 传统方式的问题 | CI带来的改善 |
|---|---|---|
| 版本追溯 | 版本靠文件名和人工记录，易混淆 | 每次提交自动记录版本、作者、时间与变更内容 |
| 质量反馈 | 问题常在现场调试时才暴露 | 提交后自动编译与检查，问题在早期暴露 |
| 协作效率 | 多人修改同一项目易冲突、难合并 | 分支管理、合并请求、代码评审形成规范流程 |
| 交付可信 | 交付物与测试结果缺乏关联 | 构建产物与测试报告绑定，形成可复现交付 |
尤其对于汽车产线、物流分拣、水处理、能源监控等连续运行场景，PLC程序的任何一次非受控修改都可能带来停机风险。CI的价值在于把“修改—验证—发布”变成一条有记录、有检查、有回退路径的流水线。
三、整体知识框架：一条从代码到现场的流水线
本课程的知识框架可以理解为一条纵向流水线，同时辅以横向的支撑体系。纵向主线包括：源码管理、自动构建、静态检查、自动测试、产物归档、部署验证。横向支撑包括：工具链选型、脚本编写、环境隔离、权限与安全、度量与改进。
图中上半部分是CI主流水线的六个关键环节，下半部分左侧是支撑体系，右侧是典型应用场景。学习时建议沿着主流水线逐段深入，同时理解支撑体系如何为流水线提供稳定运行的基础。
四、典型应用场景与案例
以一个汽车零部件焊装车间为例。该车间有12个PLC站点，分别控制机器人、夹具、输送线和安全系统。过去每次车型切换，工程师需要逐站修改程序并现场下载，版本记录靠Excel维护。引入CI后，流程变为：工程师在Git分支上修改对应站点的程序块，提交合并请求；CI服务器自动导出程序、执行编译和命名规则检查，并调用仿真环境运行关键互锁逻辑测试；通过后自动生成带版本号的交付包和测试报告，由负责人审批后发布到现场。整个过程从“人盯人”变为“流水线把关”，版本混乱和漏改问题显著减少。
另一个典型场景是标准化程序库的维护。许多企业会沉淀自己的功能块库，例如电机控制、报警处理、配方管理。CI可以对这些库执行统一编译和接口兼容性检查，防止某个工程师修改库接口后影响其他项目。
五、常见误区与学习建议
误区一：认为CI就是装一个Jenkins。工具只是载体，真正的难点在于把PLC程序的导出、编译、测试环节脚本化，并定义清楚质量门禁。
误区二：追求全自动而忽略现场安全。PLC程序最终要控制真实设备，自动部署必须设置人工审批和回退机制，不能把CI当成无人值守的下载器。
误区三：一开始就追求大而全。建议从“自动编译+静态检查”这一最小闭环开始，再逐步加入仿真测试和部署验证。
学习本课程时，建议准备一个真实的PLC项目作为练习对象，边学边搭。每学完一个环节，就把该环节接入自己的流水线，最终形成一条属于自己的PLC程序CI流水线。下面给出一个最小化的流水线配置示意，帮助建立整体印象：
stages:
- export # 从PLC工程导出源码与组态
- build # 自动编译，检查语法与块完整性
- lint # 静态规则检查：命名、未使用变量、重复线圈
- test # 仿真运行关键逻辑，执行回归断言
- package # 生成带版本号的交付包与测试报告
- deploy # 人工审批后发布到目标站点
rules:
- 任一阶段失败，立即停止并通知提交人
- 主分支合并前必须通过 build、lint、test
- 部署阶段必须由项目负责人手动确认
这条流水线并不复杂，但它把PLC程序开发从“个人手艺”推向了“工程流程”。接下来的章节将围绕这条主线，逐一展开每个环节的具体做法、工具选型和落地细节。