研发制品归档按“定范围—定规则—收集与校验—入库登记—复核与冻结—检索与处置”六步执行。先明确哪些构建产物、发布包、文档与配套件属于归档对象，再确定命名、版本、校验值、保留期与权限规则；每次发布或里程碑结束时由构建负责人提交制品与校验信息，配置管理员核对完整性后入库登记，评审通过后冻结为可追溯版本，并保留检索入口与到期处置记录。本文聚焦归档动作本身，配置基线的建立与变更、制品仓库的底层开发运维不在讨论范围。
要点总览（TL;DR）
- 归档范围按“可交付、可复现、需追溯”三条标准划定，覆盖构建产物、发布包、安装介质、配套文档和第三方依赖清单，配置基线与制品仓库底层开发不在本文范围。
- 归档规则要固定命名结构、版本与需求/缺陷/发布记录的对应关系、哈希校验值的生成时机，以及保留期和访问权限分级。
- 执行按六步走：定范围、收集与校验、入库登记、复核与冻结、检索与处置；每步明确输入、动作、输出和完成标志，校验不一致的制品退回重建。
- 构建负责人提交制品与校验值，配置管理员核对登记，评审角色复核可追溯性，项目负责人确认归档完成并做发布放行判断。
- 归档合格以检查清单判定：制品全部入库且校验一致、能关联版本与发布记录、权限与保留期已设置；校验不一致、元数据缺失、同名覆盖未禁止属于阻断项。
归档对象与范围怎么划定
归档范围的第一步是列清“要交出去、要能重建、要被追溯”的东西。判定时用三条标准：可交付、可复现、需追溯，满足其中任意一条即纳入归档。这样既能覆盖对外发布的资产，也能覆盖内部复现和审计所需的材料，避免范围过窄导致日后找不到对应版本。
按交付形态，归档对象通常分为以下几类，可据此形成范围表：
| 类别 | 典型内容 | 判定依据 | 责任来源 |
|---|---|---|---|
| 构建产物 | 编译生成的二进制、库文件、镜像 | 可复现、需追溯 | 构建负责人 |
| 发布包 | 对外发布的版本包、补丁包 | 可交付、需追溯 | 发布负责人 |
| 安装介质 | 安装程序、部署脚本、初始化数据 | 可交付、可复现 | 发布负责人 |
| 配套文档 | 发布说明、用户手册、接口文档 | 可交付、需追溯 | 文档负责人 |
| 第三方依赖清单 | 依赖组件及版本、许可证信息 | 可复现、需追溯 | 构建负责人 |
范围表要写清每类对象的来源，即由谁在哪个环节产出，这样后续收集时不会漏项。需要区分的是，组织配置基线的建立与变更、制品仓库自身的开发与运维属于另外的管理主题，本文只处理归档动作，不展开这两部分。范围一旦确定，应在发布计划中同步，作为后续归档清单的输入。
归档规则怎么定：命名、版本与校验
归档规则的作用是让每次归档都能按同一套方式重复执行，减少人工判断。规则至少覆盖命名、版本对应、校验与保留权限四个方面。
命名结构建议采用“产品/项目—版本—构建号—制品类型—日期”，各段用统一分隔符，避免空格和特殊字符。命名中带构建号，可以区分同一版本的多次构建；带日期，便于按时间检索。命名规则应写成文档，构建脚本按规则自动生成文件名，减少手工改名带来的不一致。
版本对应关系要明确：每个归档制品需关联到具体的版本号，并记录该版本对应的需求条目、缺陷修复和发布记录。这样从制品可以反查到需求，从发布记录也能找到制品。版本号与构建号的对应关系应在构建时写入元数据，而不是事后补录。
完整性校验采用哈希值，在制品生成时同步计算并写入元数据，归档时由配置管理员重新计算比对。元数据字段建议包括：制品名称、版本、构建号、制品类型、生成时间、哈希值、构建负责人、关联需求或发布单号、密级、保留期。字段清单确定后，登记环节按字段填写，避免遗漏。
保留期与权限按密级分级设置：对外发布类制品保留期较长，内部构建产物可按发布周期设定；访问权限区分只读、下载、管理三类角色，普通研发人员只读，配置管理员具备管理权限。保留期到期后的处置方式也应在规则中写明，例如清理前通知、清理后留痕。
六步操作流程：从收集到冻结
六步流程把归档从一次性动作变成可重复执行的例行工作。每一步都明确输入、动作、输出和完成标志，便于执行和检查。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 定范围 | 发布计划、版本需求清单 | 按范围表列出本次需归档的制品类别与数量 | 归档清单 | 清单经发布负责人确认 |
| 收集与校验 | 归档清单、构建产物 | 构建负责人提交制品、哈希值与构建说明；配置管理员重新计算校验值并比对 | 校验记录 | 全部制品校验一致 |
| 入库登记 | 校验通过的制品与元数据 | 按字段清单写入元数据，关联版本、需求与发布记录 | 入库登记记录 | 元数据字段完整、关联关系可查 |
| 复核与冻结 | 入库登记记录 | 评审角色核对完整性与可追溯性，通过后锁定版本，禁止同名覆盖 | 冻结版本记录 | 评审通过并完成锁定 |
| 检索与处置 | 冻结版本、保留期规则 | 提供检索入口；到期按规则清理并记录处置结果 | 检索记录、处置留痕 | 检索可用、处置有记录 |
定范围环节以发布计划为输入，输出归档清单，清单要列明制品名称、类型和责任人。收集与校验环节由构建负责人提交制品和校验值，配置管理员独立复核，校验不一致的制品退回重新构建，不进入登记。入库登记环节把元数据写入登记记录，并建立与版本、需求、发布单的关联。复核与冻结环节由评审角色确认完整性和可追溯性，通过后锁定，同名制品不允许覆盖，需要变更时走新版本。检索与处置环节保证归档后能被找到，到期清理按规则执行并留下记录。
在流程承载上，归档清单、元数据登记和评审记录可以放在工作项与文档中管理，让每个制品的状态、责任人和关联版本在同一处可见，评审通过后锁定记录，便于后续检索和追溯。ONES 可用于承载这类清单与评审记录，具体用法按团队现有流程配置。
角色分工与交付物
归档涉及多个角色，职责边界不清容易出现“都以为别人做了”的情况。下表按角色列出职责与交付物，便于对照执行。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 构建/发布负责人 | 按清单提交制品、哈希值与构建说明，确保制品可复现 | 制品文件、校验值、构建说明 |
| 配置管理员 | 核对完整性、登记入库、维护命名与保留规则 | 校验记录、入库登记记录、规则文档 |
| 质量或评审角色 | 复核归档完整性与可追溯性，确认是否符合规则 | 评审记录、复核结论 |
| 项目负责人 | 确认归档完成，承担发布放行判断 | 归档完成确认、发布放行记录 |
构建负责人对提交内容的真实性负责，配置管理员对登记质量和规则一致性负责，评审角色对复核结论负责，项目负责人对是否放行负责。四类交付物分别对应提交、登记、复核和放行四个节点，任一节点缺失都会影响归档的完整性判定。
一个完整示例：版本发布后的归档过程
以下为演示情景：某产品完成一次常规版本发布，包含安装包、用户手册和第三方依赖清单。按六步走一遍，展示记录形态。
定范围：发布计划确认本次发布版本为 V2.3，归档清单列出安装包、用户手册、依赖清单三类共五项制品，责任人分别为发布负责人和文档负责人。收集与校验：发布负责人提交安装包及哈希值，文档负责人提交手册，构建负责人提交依赖清单；配置管理员重新计算哈希值，五项全部一致，形成校验记录。入库登记：按字段清单登记制品名称、版本 V2.3、构建号、类型、生成时间、哈希值、责任人、关联发布单号，并关联到对应需求条目。复核与冻结：评审角色核对五项制品齐全、关联关系可查，通过后锁定 V2.3 版本，同名制品禁止覆盖。检索与处置：在登记记录中可按版本号和制品类型检索，保留期按规则设定，到期清理前通知责任人并留痕。
这个示例中容易遗漏的是依赖清单与文档版本的对应：依赖清单要标注对应的构建号，手册要标注适用的版本号，否则日后复现时无法确认文档与制品是否匹配。另一个易漏点是哈希值在提交后重新计算，若只在构建时记录一次，传输过程中的损坏无法发现。
完成检查：归档是否合格的核对项
归档是否完成，用一份检查清单逐项核对，全部通过才算合格。检查分为完整性、可追溯、权限与保留期三类，并设阻断项。
- 完整性检查：清单内制品是否全部入库，哈希值与提交值是否一致，构建说明是否齐全。
- 可追溯检查：每个制品能否关联到版本号、需求条目和发布记录，依赖清单与文档版本是否对应。
- 权限与保留期检查：访问范围是否按密级设置，保留期是否已登记，到期处置方式是否明确。
阻断项包括：校验不一致、元数据字段缺失、同名覆盖未禁止。出现任一阻断项，归档判定为不合格，需退回对应环节处理后再复核。检查结果与评审记录一并留存，作为发布放行的依据。
常见问题
归档时哈希值应该在什么时候计算，提交后还要再算一次吗？
哈希值应在制品生成时同步计算并写入元数据，作为该制品的初始校验值。归档提交后，配置管理员需要重新计算一次并与提交值比对，目的是发现传输或存储过程中的损坏。只在构建时记录一次、提交后不再复核，就无法确认入库的制品与构建产物一致。两次计算的结果都应保留在校验记录中。
同名制品需要更新时怎么处理，能直接覆盖吗？
冻结后的同名制品不应直接覆盖。需要变更时按新版本或新构建号重新走收集、校验、登记和复核流程，原冻结版本保持可查。规则中应明确禁止同名覆盖，并将其列为归档检查的阻断项；一旦发现覆盖，归档判定为不合格，需恢复原记录并重新复核。
保留期到期后，归档制品应该怎么处置？
处置方式要在归档规则中提前写明，通常包括到期前通知责任人、清理后留下处置记录。对外发布类制品保留期可设得较长，内部构建产物可按发布周期设定。清理动作需要可追溯，记录清理时间、执行人和涉及制品，避免日后无法解释某版本为何缺失。
小团队人少，角色分工可以合并吗？
可以合并角色，但要保留职责分离的关键点。构建提交与入库核对最好由不同人执行，至少做到提交人不能独自确认校验结果；评审复核可以由项目负责人兼任。合并后应在规则文档中写明谁承担哪几项职责，避免提交、登记、复核、放行四个节点出现无人负责的情况。
归档清单和评审记录放在哪里管理比较合适？
关键是让制品状态、责任人、关联版本和评审结论在同一处可见，并能按版本检索。可以用工作项承载归档清单、用文档记录元数据与评审结论，评审通过后锁定记录。ONES 可用于承载这类清单与评审记录，具体字段和流程按团队现有做法配置。
