📚 课程目录第3章发布流程基础

3. 发布流程基础

在自动化项目中，代码评审通过并不等于可以立即上线。发布流程是把“已验证的变更”安全、可追溯地交付到目标环境的工程机制。它既包含技术动作，也包含审批、回滚、观测和沟通等管理动作。理解发布流程的基本概念、阶段划分和常见策略，是后续设计发布流水线、制定回滚方案和评审发布风险的基础。

核心定义：软件发布流程是指从代码合并、构建、测试、部署到验证、监控和回滚的一整套受控活动。它的目标不是“把包传上去”，而是让每次变更在可控风险下到达生产环境，并且出问题时能快速恢复。

一、发布流程的基本概念

发布流程中常出现几个容易混淆的术语，需要先区分清楚：

构建（Build）：把源码、依赖、配置和资源编译打包成可部署的制品，例如 Docker 镜像、JAR 包、安装包或 PLC 程序归档。
发布（Release）：把某个制品版本正式标记为可交付，并决定它进入哪个环境、面向哪些用户或设备。
部署（Deploy）：把制品安装、启动或更新到目标环境中的技术动作。
回滚（Rollback）：当发布后出现异常时，恢复到上一个稳定版本或关闭新功能入口。
灰度（Canary / Gray）：先让少量用户或设备使用新版本，观察指标后再逐步扩大范围。

在自动化项目中，发布对象往往不只是软件服务，还可能包括 PLC 程序、HMI 画面、机器人程序、SCADA 配置、边缘网关固件和数据库脚本。因此发布流程必须覆盖“软件+配置+硬件参数”的组合版本。

二、发布流程的阶段划分

一个完整的发布流程通常划分为六个阶段：

准备阶段：确认发布范围、版本号、变更清单、依赖项、回滚方案和责任人。
构建与制品管理：触发流水线，生成唯一版本号，上传制品库并记录校验值。
测试验证：在测试环境执行单元测试、集成测试、回归测试和现场信号仿真。
预发布验证：在准生产环境验证配置、网络、数据库和外部接口，确认与生产差异。
生产部署：按发布策略逐步替换或更新目标对象，并实时监控关键指标。
发布后验证与收尾：确认业务指标、日志、告警和现场设备状态，更新发布记录并关闭变更单。

下面这张图展示了发布流程从代码到生产的阶段流转，以及每个阶段的关键产物和回滚触发点。

三、常见发布策略：蓝绿、金丝雀与滚动

发布策略决定了新版本如何替换旧版本，直接影响风险范围和回滚速度。自动化项目中最常用的是蓝绿、金丝雀和滚动三种。

策略	基本做法	优点	风险与限制	适用场景
蓝绿发布	维护两套完整环境，蓝为旧版、绿为新版，验证后切换流量	切换快、回滚快，几乎瞬时恢复	资源成本高，数据库兼容需提前处理	核心 SCADA、MES 服务、停机窗口短的产线
金丝雀发布	先让少量设备或用户使用新版本，观察后再扩大	风险范围小，可基于真实指标决策	需要流量或设备分组能力，观察周期较长	边缘网关、采集服务、多产线逐步推广
滚动发布	逐批替换实例或设备，始终保持部分旧版本在线	资源占用低，无需额外整套环境	新旧版本可能并存，回滚需逐批处理	无状态服务、多节点采集集群、PLC 程序分批下载

选择建议：如果系统有状态、数据库变更复杂，优先考虑蓝绿；如果设备分布广、现场验证成本高，优先考虑金丝雀；如果服务无状态、节点多，滚动发布更经济。实际项目中也可以组合使用，例如先金丝雀验证，再滚动扩大。

四、自动化项目发布的特殊之处

自动化项目的发布与互联网软件发布有明显差异，主要体现在以下方面：

发布对象混合：一次发布可能同时包含后端服务、边缘程序、PLC 逻辑、HMI 画面和数据库脚本，版本必须统一编排。
停机窗口受限：产线不能随意停，发布往往要安排在换班、检修或计划停机时段。
现场验证不可替代：仿真通过不代表现场通过，必须验证真实 I/O、通信链路、节拍和联锁逻辑。
回滚成本高：PLC 程序回滚可能需要重新下载并重启设备，HMI 配置回滚也可能影响操作员习惯。
安全与合规要求：涉及安全 PLC、联锁和报警的变更，必须保留审批记录和版本追溯。

因此，自动化项目的发布流程通常需要增加“现场确认”和“分批推广”两个环节。下面是一段典型的发布前检查命令示例，用于确认制品版本和配置一致性：

# 查看当前部署版本与制品库记录
$ release-cli status --env prod --project line-a
current_version: v2.4.1
artifact_hash: 9f3c7a1e
config_revision: cfg-20240612-03
last_deploy_time: 2024-06-12 02:15:33

# 校验回滚包是否可用
$ release-cli rollback-check --env prod --project line-a
rollback_target: v2.4.0
rollback_artifact: OK
db_script_reversible: YES
estimated_rollback_time: 4m30s

五、案例与常见误区

案例场景：某汽车零部件产线需要更新边缘采集程序，同时调整 HMI 报警阈值。团队采用金丝雀策略，先在一号工位试点 24 小时，确认数据采集完整、报警无误后再推广到其余 11 个工位。发布后第二天发现某型号 PLC 通信偶发超时，由于只影响一个工位，团队迅速回滚该工位并保留其他工位新版本，避免了整线停机。

常见误区：

只发布软件，不发布配置和数据库脚本，导致版本不一致。
没有回滚方案就上线，出问题后只能现场改代码。
把测试环境通过等同于生产可用，忽略现场网络和设备差异。
发布后不监控关键指标，问题由操作员先发现。
所有产线一次性全量发布，风险无法收敛。

复盘时建议回答三个问题：本次发布的范围是否清晰？回滚是否在预期时间内完成？现场验证是否覆盖了真实工况？把答案记录到发布报告中，下一次发布的风险就会显著降低。

掌握发布流程的基本概念、阶段划分和策略选择后，就可以进一步设计适合自动化项目的发布流水线，把构建、测试、部署、验证和回滚串成可重复执行的工程能力。