工业软件的交付节奏与互联网产品有结构性差异。互联网应用可以每天发布数十次，A/B测试快速验证，失败就回滚。OT侧软件直接控制物理设备，一次异常发布可能导致产线停机甚至安全事故。这种差异决定了工业互联网平台的CI/CD流水线不能照搬互联网实践，需要面向OT约束做深度适配。
流水线阶段设计
CI/CD流水线的核心价值在于将"从代码到可部署制品"的过程标准化、自动化和可审计。工业平台的流水线分六个阶段，每个阶段有明确的准入准出条件。
代码提交阶段触发静态分析。SonarQube扫描代码异味、安全漏洞和圈复杂度。工业场景对安全编码要求更高——CWE Top 25中的漏洞模式需在提交时拦截。Git Hooks或GitLab CI的Pre-merge Pipeline在MR（Merge Request）阶段运行静态检查，不通过则拒绝合入。
构建阶段生成制品。Java应用打为Fat JAR或Docker镜像，Python应用打包为Wheel + Docker镜像。工业场景的特殊需求是多架构构建——平台服务部署在x86服务器（amd64），边缘采集服务可能部署在ARM设备（arm64）。Docker Buildx支持多架构镜像构建，一次命令生成两个架构的镜像并推送到统一Manifest。
测试阶段是最耗时的环节，也是工业CI/CD与互联网差异最大的环节。
安全扫描阶段在制品构建完成后运行。Trivy扫描容器镜像中的CVE漏洞，Syft生成SBOM（软件物料清单）。工业平台的供应链安全要求日益严格——等保2.0三级要求对软件成分有完整审计能力。
部署阶段和验证阶段构成了CD（Continuous Delivery）部分。
测试策略：从单元到硬件在环
工业软件测试的复杂度远超互联网应用，因为存在物理设备依赖。
单元测试覆盖核心逻辑——协议解析函数、数据转换函数、告警规则匹配函数。覆盖率要求80%以上，但工业场景的单元测试有特殊挑战：协议解析依赖设备原始报文，测试数据是二进制流，难以人工构造。解决方案是录制真实设备报文作为测试夹具，版本化存储在测试数据仓库中。
集成测试验证服务间交互。使用Testcontainers在CI环境中启动依赖中间件（Kafka/Redis/TDengine），测试采集服务到存储服务的数据流完整性。Testcontainers的优势是每个测试用例独立启动容器，互不干扰，测试完成后自动清理。
仿真测试是工业场景特有的层次。数字孪生技术在这里找到了一个务实应用——不是给产线做3D可视化，而是在CI环境中运行设备仿真器，模拟PLC数据上报、设备状态变化、故障场景。采集服务连接仿真器而非真实设备，验证从数据采集到告警触发的完整链路。
硬件在环测试（HIL）对安全关键系统不可省略。控制指令类服务（下发到PLC的启停指令）必须在真实硬件上验证，仿真器无法复现PLC的固件行为和通信时序。HIL测试台架包含真实PLC、传感器和执行器，CI流水线通过远程测试框架触发HIL测试用例。由于HIL资源稀缺，通常只在Release Candidate阶段运行，不在每次提交时触发。
测试层次 | 覆盖目标 | 执行频率 | 工业特殊要求 |
单元测试 | 核心函数逻辑 | 每次提交 | 设备报文测试夹具 |
集成测试 | 服务间交互 | 每次MR | Testcontainers依赖隔离 |
仿真测试 | 端到端链路 | 每日构建 | 设备仿真器 |
HIL测试 | 控制指令正确性 | Release阶段 | 真实PLC硬件 |
部署策略：蓝绿与金丝雀的工业适配
蓝绿部署在OT场景中需审慎使用。蓝绿部署需要双倍资源——两套环境同时运行，切换流量到新版本。工业场景的双倍资源成本不只是服务器，还有设备连接——PLC只连一个采集服务地址，蓝绿切换意味着设备端需要重新配置采集服务地址，这在OT环境中操作成本极高。
金丝雀发布更适合工业场景。新版本部署到部分节点，只接入部分产线流量。灰度规则按产线维度划分——先在非关键产线（如包装线）部署新版本，验证48小时无异常后再推广到关键产线（如装配线）。金丝雀发布的核心是可观测性——新版本的错误率、延迟、数据完整性指标需实时监控，超阈值自动回滚。
A/B测试在工业场景的应用比较有限。工业软件的正确性通常是确定性的而非概率性的——设备数据是否正确采集，答案是"是"或"否"，不需要统计显著性验证。A/B测试更多用于UI层面的优化（大屏布局、报表格式），不用于核心数据链路。
配置即代码
基础设施即代码（IaC）是CI/CD的基石。工业平台的环境管理比互联网应用更复杂——开发/测试/生产环境的差异不只是配置值不同，连基础设施拓扑都不同。
Terraform管理基础设施——虚拟机、网络、存储卷。工业私有云（如OpenStack）的IaC支持通过Provider扩展。Terraform State文件是核心——存储了基础设施的实际状态与声明状态的映射。生产环境的State文件需远程存储（S3/OSS）并加锁，防止并发修改导致状态不一致。
Ansible做配置管理——操作系统初始化、安全加固、中间件配置。Ansible Playbook版本化管理，每次配置变更走Code Review。工业场景的Playbook需要幂等性保证——同一Playbook执行多次结果一致，避免重复执行导致的配置漂移。
K8s Manifest通过Helm Chart版本化管理。Chart的values.yaml按环境拆分——values-dev.yaml、values-prod.yaml，部署时选择对应values文件。Chart版本号遵循SemVer规范，Release流水线中Chart版本与镜像版本绑定，追溯性清晰。
制品管理
制品管理的核心是可追溯——给定一个生产环境运行的Pod，能追溯到它的源码Commit、构建时间、测试结果和安全扫描报告。
容器镜像仓库（Harbor）存储镜像并附带元数据。Harbor的镜像签名功能（Notary v2 / Cosign）确保镜像在构建后未被篡改——CI流水线在构建完成后签名镜像，部署前校验签名，不匹配则拒绝部署。
Helm Chart版本与镜像版本分离管理。Chart定义了部署模板，镜像Tag引用具体版本。Chart本身也需版本化——v1.2.0的Chart可能同时支持v2.1和v2.2的镜像。Chart仓库（ChartMuseum/Harbor）存储Chart包，helm pull获取指定版本。
落地挑战
OT环境无CI/CD基础设施是最现实的障碍。工厂机房里没有GitLab Runner、没有Docker Registry、甚至没有K8s。采集服务部署在工业PC或网关设备上，这些设备资源有限，无法运行Docker。解决方案是交叉部署——在IT侧（数据中心）构建制品，通过工厂内网文件传输（SFTP/NFS）分送到OT侧设备，OT侧运行轻量部署代理（Agent）执行部署和健康检查。
生产环境不允许自动化部署是安全合规要求。OT系统变更需人工审批（变更管理委员会CCB），CI/CD流水线到"待部署"状态停止，不自动执行生产部署。审批通过后，运维人员手动触发部署按钮。这种半自动化模式是工业CI/CD与互联网CI/CD的关键差异——CI做到全自动化，CD到生产环境保留人工卡点。
TDengine在CI/CD体系中支持Helm部署和Operator管理。流水线中TDengine的部署通过Helm Chart一键完成——helm install tdengine tdengine-helm/tdengine -f values-prod.yaml。版本回滚通过helm rollback tdengine <revision>执行，秒级回退到上一个稳定版本。Operator管理集群的扩缩容和节点恢复，CI/CD流水线只需触发CRD变更，Operator负责具体执行。
结语
CI/CD在工业软件中的实践，核心矛盾是交付效率与生产安全之间的平衡。CI阶段的自动化可以做到极致——从提交到制品产出，全流程无人值守。CD阶段到生产环境的部署，则需要保留人工审批节点，这是OT安全合规的刚性约束。
测试策略的分层设计决定了发布质量的上限——从单元测试到HIL测试，每一层覆盖不同的缺陷类型。制品管理的可追溯性则决定了故障定位的速度——当生产环境出现异常，几分钟内锁定Commit和变更内容是工程成熟度的标志。在数据层，原生支持容器化部署和版本管理的数据平台可以简化整个CI/CD链路中数据基础设施的交付负担。
