交付清单和发布记录要解决的核心问题，是让任何一个交付物都能反查到它的构建、代码版本和经手人。为此需要记录四类字段：制品标识（名称、版本号、校验值）、来源链路（代码仓库地址、提交号或标签、构建任务与构建编号）、经手信息（构建人、审核人、交付确认人及时间）、状态与去向（发布批次、目标环境、交付对象）。清单登记交付物本体，发布记录登记一次发布中各制品的来源与状态，两者用制品唯一标识关联。
要点总览（TL;DR）
- 交付清单和发布记录需记录四类字段：制品标识（名称、版本号、校验值）、来源链路（代码仓库地址、提交号或标签、构建任务与构建编号）、经手信息（构建人、审核人、交付确认人及时间）、状态与去向（发布批次、目标环境、交付对象）。
- 清单登记交付物本体，一个制品一条记录；发布记录登记一次发布中各制品的来源、状态与去向，两者通过“制品名称+版本号+校验值”唯一标识关联。
- 反查路径为：交付物→清单条目→发布批次→发布记录→构建编号→提交号或标签→经手人，校验值用于确认交付文件与构建产物一致。
- 角色分工遵循“谁产生谁填写、谁审核谁签署”：构建执行人填构建与提交信息，制品管理员维护清单条目，审核与交付确认人签署记录。
- 检查时随机抽取交付物做端到端反查，以能否定位到构建、代码版本和经手人作为通过标准；必填字段缺失或标识不一致应阻断交付。
制品来源字段清单：四类字段与填写口径
字段设计的目标是“可反查”，因此每一项都要能回答一个具体问题：这是什么制品、它从哪来、谁经手、去了哪。四类字段分别承担这四个问题，缺一类，追溯链路就会断在某个环节。下表给出建议字段、填写口径和必填程度，团队可据此建表。
| 类别 | 字段名 | 含义 | 填写口径 | 必填 |
|---|---|---|---|---|
| 制品标识 | 制品名称 | 交付物的正式名称 | 与构建产物名称一致，不使用内部简称 | 必填 |
| 版本号 | 该制品的版本 | 遵循组织版本规范，与构建时写入的版本一致 | 必填 | |
| 文件校验值 | 制品文件的哈希值 | 对最终交付文件计算，算法在团队内统一 | 必填 | |
| 来源链路 | 代码仓库地址 | 制品对应的代码库位置 | 填写可定位到仓库的地址，含分支信息时注明 | 必填 |
| 提交号或标签 | 构建所用的代码版本 | 优先填标签；无标签时填提交号 | 必填 | |
| 构建任务与构建编号 | 产出该制品的构建 | 构建任务名称加本次构建编号，二者组合唯一 | 必填 | |
| 经手信息 | 构建人及构建时间 | 执行构建的人与时间 | 由构建执行人填写，时间取构建完成时刻 | 必填 |
| 审核人及审核时间 | 对制品来源与质量签署的人 | 由审核人本人签署，不代签 | 必填 | |
| 交付确认人及确认时间 | 确认交付的人与时间 | 在交付动作发生时填写 | 必填 | |
| 状态与去向 | 发布批次 | 该制品所属的发布批次 | 与发布记录中的批次号一致 | 必填 |
| 目标环境 | 制品部署或交付的环境 | 按环境命名规范填写 | 必填 | |
| 交付对象 | 接收该制品的团队或客户 | 填写实际接收方，不填内部代称 | 必填 | |
| 当前状态 | 制品在交付流程中的位置 | 使用统一状态值，如待审核、已审核、已交付、已回退 | 必填 |
上述字段中，校验值最容易被省略，但它恰恰是确认“交付的文件就是构建产出的文件”的关键。若团队初期字段过多难以落地，可先保证制品标识、提交号、构建编号、构建人与交付确认人齐全，再逐步补齐审核与状态字段；但校验值不建议降为选填，否则同名不同构建的混淆无法排除。
从交付物反查构建、代码版本和经手人的追溯链路
字段只有串成链路才有追溯价值。关联主键建议采用“制品名称+版本号+校验值”的组合：名称和版本区分制品，校验值区分同一版本下的不同构建，三者合起来能唯一定位一个交付物条目。
反查路径按以下顺序走通：
- 拿到交付物，计算其校验值，在交付清单中按名称、版本、校验值定位条目。
- 从清单条目找到关联的发布批次，进入对应发布记录。
- 在发布记录中读取构建任务与构建编号，定位到具体构建。
- 由构建记录读取提交号或标签，回到代码仓库确认代码版本。
- 由构建人、审核人、交付确认人字段确认各环节经手人及时间。
清单与发布记录的分工需要明确：清单是交付物的登记簿，一个制品一条记录，记录其本体信息和来源字段；发布记录描述一次发布事件，登记该批次中每个制品的来源、状态与去向。同一次发布可能包含多个制品，因此发布记录与清单条目是一对多关系，通过制品唯一标识关联。校验值在这条链路中承担一致性校验的作用：清单中的校验值与发布记录中登记的校验值必须相同，若不同，说明交付的文件与记录的来源发生了错配，应阻断交付并回查构建环节。
当团队在平台上管理这些记录时，可以把清单条目和发布记录作为工作项或文档维护，并与构建、代码提交建立关联。ONES ALM 方案围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯；其数字线程用于连接需求、开发、测试、变更和发布等环节，需求变化时可沿关联关系分析受影响的任务、测试和交付内容，并保留过程追踪和审计依据。这为上述反查路径提供了承载方式，具体字段结构仍需结合实施配置确定。
角色分工与各环节交付物
字段无人维护是追溯失效的常见原因。分工原则是“谁产生谁填写、谁审核谁签署”，每个角色在固定时点完成自己的字段，并留下可核对的记录。
| 角色 | 输入 | 动作 | 负责字段 | 输出与完成标志 |
|---|---|---|---|---|
| 构建/发布执行人 | 待构建的代码版本、构建任务 | 执行构建，记录构建结果 | 构建编号、提交号或标签、校验值、构建人及时间 | 构建记录填写完整，校验值已生成 |
| 制品管理员或配置管理员 | 构建记录、版本计划 | 登记交付清单条目，核对版本对应关系 | 制品名称、版本号、仓库地址、清单条目状态 | 清单条目与构建记录一一对应，无孤立条目 |
| 审核人 | 清单条目与构建记录 | 核对来源字段与校验值，签署审核意见 | 审核人及审核时间、审核结论 | 审核记录已签署，结论明确 |
| 交付确认人 | 已审核的清单条目、发布计划 | 确认交付对象与环境，登记发布记录 | 发布批次、目标环境、交付对象、交付确认人及时间、当前状态 | 发布记录状态更新为已交付，交付对象可查 |
时点上，构建字段在构建完成时填写，清单条目在制品入库或纳入交付范围时登记，审核在交付前完成，交付确认在实际交付动作发生时记录。每个角色的完成标志都是下一环节的输入前提，缺少签署的记录不应进入下一状态。
填写示例：一次发布的清单与记录
以下为演示情景，用于说明字段如何填写和关联，不代表任何真实项目数据。
示例交付清单条目：
| 制品名称 | 版本号 | 校验值 | 仓库地址 | 提交号/标签 | 构建任务与编号 | 构建人/时间 | 状态 |
|---|---|---|---|---|---|---|---|
| 订单服务 | 2.4.0 | a1b2c3…（哈希） | 示例仓库地址 | v2.4.0 | order-build #118 | 张工 / 3月12日 10:20 | 已审核 |
示例发布记录条目：
| 发布批次 | 制品标识 | 构建编号 | 提交号/标签 | 审核人 | 交付确认人/时间 | 目标环境 | 交付对象 | 状态 |
|---|---|---|---|---|---|---|---|---|
| R2024-03 | 订单服务 2.4.0 / a1b2c3… | order-build #118 | v2.4.0 | 李工 | 王工 / 3月12日 15:40 | 生产环境 | 某业务团队 | 已交付 |
反查演示：交付对象反馈订单服务有问题，接收到的文件校验值为 a1b2c3…。在清单中按名称、版本、校验值定位到条目，确认构建为 order-build #118，代码版本为标签 v2.4.0，构建人为张工；进入发布批次 R2024-03，确认审核人为李工、交付确认人为王工，目标环境为生产环境。整条链路在一个页面内即可走通。
本示例只覆盖制品来源字段的填写与关联，不涉及配置基线的建立与维护，也不涉及制品仓库的底层存储实现，这两部分属于其他管理主题。
完成检查：字段完整性与追溯可用性核验
检查不能只看字段是否填满，还要看链路能否走通。建议在每次发布前和定期审计时执行以下检查项。
| 检查项 | 检查方法 | 通过标准 |
|---|---|---|
| 必填字段完整性 | 逐条核对清单与发布记录的必填字段 | 无空值，无占位符或默认值充数 |
| 制品标识一致性 | 比对清单与发布记录中同一制品的名称、版本、校验值 | 三者在两处记录中完全一致 |
| 端到端反查 | 随机抽取若干交付物，按反查路径走一遍 | 能定位到构建编号、提交号或标签、各环节经手人 |
| 校验值有效性 | 对交付文件重新计算校验值并与记录比对 | 计算结果与记录一致 |
| 状态与签署 | 核对审核与交付确认是否由本人签署、时间是否合理 | 签署人、时间与流程顺序相符 |
出现以下情况应阻断交付并整改：必填字段缺失；清单与发布记录的制品标识不一致；抽样反查无法定位到构建或代码版本；交付文件校验值与记录不符。整改后需重新执行对应检查项，通过后方可继续交付。检查结果建议留存记录，作为后续审计和流程改进的依据。ONES ALM 方案可将标准流程、评审节点、交付物模板和过程数据沉淀为可复用资产，团队可以把上述检查表和字段模板固化为可复用的交付物模板，减少每次发布重复设计的工作。
常见问题
如果团队初期字段太多难以落地，应该优先保证哪些字段？
可先保证制品标识（名称、版本号、校验值）、提交号或标签、构建编号、构建人与交付确认人齐全，再逐步补齐审核与状态字段。校验值不建议降为选填，否则同名不同构建的混淆无法排除。
交付清单和发布记录中的制品标识不一致时如何处理？
应立即阻断交付并回查构建环节。重点比对名称、版本号和校验值三项，若任一不一致，说明交付的文件与记录的来源发生了错配，需重新核对构建记录与交付文件，整改后重新执行一致性检查。
校验值应该用什么算法计算，是否有统一要求？
算法由团队统一约定即可，常见如 SHA-256 等。关键是对最终交付文件计算，并在清单与发布记录中登记同一算法得出的值，确保两处可比对。算法本身不构成追溯障碍，一致性才是关键。
发布记录与交付清单是一对多关系，具体怎么关联？
发布记录描述一次发布事件，可包含多个制品；交付清单一个制品一条记录。两者通过“制品名称+版本号+校验值”组合关联，发布记录中每个制品条目都引用对应的清单条目标识，确保从任一方向都能定位到对方。
在 ONES 中如何承载这些字段和追溯关系？
可将清单条目和发布记录作为工作项或文档维护，并与构建、代码提交建立关联。ONES ALM 方案围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯；其数字线程连接需求、开发、测试、变更和发布等环节，保留过程追踪和审计依据。具体字段结构需结合实施配置确定。
