车载软件为什么不能构建完就发？

软件发布不是按个按钮，而是一条从计划到交付的流水线，每个环节都有门禁。

软件发布流程共 11 个步骤，核心思路是两次评审、两次门禁——发布计划要审，发布内容也要审。第一次评审确保"做对了事"，第二次评审确保"事情做对了"。两次评审都通过，才能进入交付。

计划与验证

前 6 步解决一个问题：发布什么，怎么验证。

制定发布计划是整条链路的起点。发布计划不是拍脑袋写的，它要回答几个核心问题：这次发布什么类型（内部验证、客户交付、工厂量产）？版本号怎么定？包含哪些文件？时间节点在哪？需要多少人和设备资源？这些信息直接来自客户需求和项目计划。

计划写完必须评审。组织相关方坐下来过一遍，有问题就改，改完再确认所有问题关闭。这个环节看起来多余，但它防止的是"计划本身就有偏差，后面全白做"的情况。评审通过后邮件通知所有干系人，计划阶段结束。

接下来进入构建和验证。用配置管理工具（Bitbucket/Jenkins）构建软件包，按需包含签名文件。包出来之后，按计划执行软件回归测试和系统回归测试。系统回归测试要覆盖定义好的硬件版本，必要时还要验证产线测试环境和最终客户发货版本的验证内容。测试完成出具报告。

最后一步是编写发布说明（release note）。按模板填写，内容要能回答：这次发了什么、改了什么、还有什么没改。

评审与交付

后 5 步解决另一个问题：能不能发，怎么发。

评审软件发布是整条流程最关键的门禁。这次评审要逐项确认四件事：

1. 发布范围：有没有不在计划内的东西混进来了？有没有计划内但没做完的东西？
2. 测试执行：软件测试和系统测试的覆盖率和执行率是多少？原则上执行率必须 100%
3. 已知问题：未修复的问题影响范围是什么？有没有临时解决方案？需要客户确认吗？
4. 客户要求：这次发布是否满足客户的全部要求？

这四项中任何一项不通过，原则上不允许发布。如果确实有特殊情况，必须立即组织相关方确认原因、制定整改措施和补充测试计划，并与客户沟通取得书面同意。

评审通过后，流程根据发布类型分叉。内部发布直接邮件通知即可。但如果是要交付客户或工厂的版本，必须走 OA 系统提交审批流程，上传 release note 和软件包路径。

接下来召开批准发布会议。会上逐项确认发布信息、文档清单（签名文件等）、功能和非功能需求状态、变更内容、问题状态、残留问题的严重程度和影响、测试执行率和通过率。以下情况不予批准（除非客户书面同意）：

• 不满足客户要求
• 存在 Fatal 或 Critical 级 Bug
• 未执行软件测试或系统测试
• 软件或系统测试执行率小于 100%

批准后各审批人在 OA 系统确认签字，导出审批流程 PDF 归档。随后邮件通知发布结论，从配置管理库获取所有待交付文件并打包，按约定方式交付客户或工厂并通知。

角色分工

发布流程涉及多个角色，SPM 是主线负责人，驱动整个流程推进，其他人按阶段介入。

每个角色在评审和批准环节都有明确的签字权，不是走过场。发布流程的设计逻辑就是：把决策分散到每个环节，不让问题堆积到最后。