研发制品归档要把构建产物、发布包和交付文档按版本与来源绑定成可追溯的归档单元。具体做法是依次完成采集、标识、核验、入库、交付、保留六步，每一步明确输入、负责人和完成标志。本文按这六步展开操作细节，并给出角色分工、填写示例和完成检查清单；组织配置基线的建立、制品仓库底层存储架构不在讨论范围内。
要点总览（TL;DR）
- 归档对象分三类：构建产物、发布包、交付文档，各自使用独立命名规则，版本标识与来源标识分开记录。
- 主流程为采集、标识、核验、入库、交付、保留六步，每步都有输入、输出和完成标志，缺任一项即视为未完成。
- 研发、构建/发布、质量、配置管理员、交付负责人各司其职，交接以记录为准，口头确认不作为归档依据。
- 核验至少覆盖校验值比对、文件清单齐套、文档与制品版本一致三项，结果留痕作为入库审批附件。
- 用检查清单逐项核对，对象完整性、版本一致性、来源可追溯、文档齐套、审批登记、交付签收为阻断项。
归档范围与版本标识怎么定
归档范围先定清楚，后续的命名、核验和交付才有统一口径。建议把需要归档的对象分成三类，分别管理，避免用同一套编号混装。
| 归档对象 | 典型内容 | 归档粒度 | 命名与版本标识示例 |
|---|---|---|---|
| 构建产物 | 编译生成的二进制、库文件、镜像、安装介质 | 每次正式构建 | 产品代号-版本号-构建序号，如 CRM-2.4.0-b0137 |
| 发布包 | 面向环境部署的整包、补丁包、配置随包文件 | 每次对外或对生产发布 | 产品代号-版本号-发布批次，如 CRM-2.4.0-R02 |
| 交付文档 | 发布说明、部署手册、验收记录、用户文档 | 与发布包同批次 | 发布包标识加文档类型，如 CRM-2.4.0-R02-发布说明 |
版本标识建议采用“产品/项目代号-版本号-构建或发布序号”的结构，三段各自含义固定，不随项目习惯变化。来源标识单独记录，至少包含代码分支或提交号、构建任务编号、触发人和构建时间，用于回答“这个包从哪来”。版本标识回答“这是哪个版本”，来源标识回答“它由哪次构建产生”，两者分开记录，回溯时不会互相干扰。
命名规则落地时注意三点：一是字符集和分隔符统一，避免大小写、空格、下划线混用导致检索失败；二是序号只增不改，已归档的标识不复用；三是文档标识必须携带所属发布包标识，保证文档与制品能对上。规则确定后写入归档对象清单，作为后续采集和核验的依据。
六步归档流程：从采集到入库
六步流程按顺序执行，每一步都有明确输入、动作、输出和完成标志。任何一步缺少输出或完成标志未达成，本次归档视为未完成，不进入下一步。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 采集 | 构建任务记录、发布计划 | 从构建或发布环节获取制品原件，不做二次加工 | 待归档制品集合 | 制品数量与构建记录一致 |
| 标识 | 待归档制品、归档对象清单 | 按命名规则赋版本标识，记录来源信息与关联需求 | 带标识的制品与来源记录 | 每个制品都有版本标识和来源记录 |
| 核验 | 带标识的制品、文档清单 | 比对校验值，检查文件清单齐套，核对文档与制品版本一致 | 核验记录 | 三项核验全部通过并留痕 |
| 入库 | 核验通过的制品与核验记录 | 提交归档审批，审批通过后登记入库 | 归档登记表 | 审批完成且登记表填写完整 |
| 交付 | 归档登记表 | 按交付对象输出交付清单，随发布包一并移交 | 交付清单 | 接收方确认签收 |
| 保留 | 归档登记表、保留策略 | 按策略维护存储与可读性，到期前评估并走处置审批 | 保留与处置记录 | 保留期内可检索可读取，处置有审批 |
采集环节的关键是取原件。从构建系统或发布流水线直接获取产物，避免从个人目录或临时位置拷贝，否则来源记录会失真。标识环节把版本号、来源和关联需求写在一起，关联需求用于回答“这个制品对应哪些需求变更”，在问题回溯时直接可用。
核验环节至少覆盖三项：校验值比对，确认归档件与构建件一致；文件清单齐套，确认发布包内文件与清单逐项对应；文档与制品版本一致，确认发布说明、部署手册指向同一版本。三项核验结果都要留存记录，作为入库审批的附件。
入库环节把审批和登记分开：审批确认“可以归档”，登记确认“已经归档”。登记表是后续交付和保留操作的唯一索引。交付环节输出交付清单，清单内容与登记表一致，接收方签收后归档闭环。保留环节按交付合同、合规要求和内部制度确定保留期限，到期处置前评估是否仍在服务期内，处置动作留审批记录。
角色分工与各环节交付物
归档责任要落到具体角色，每个角色清楚自己交什么、交给谁。下表按角色列出职责、输入和输出物。
| 角色 | 主要职责 | 输入 | 输出物 |
|---|---|---|---|
| 研发人员 | 确认关联需求与变更范围，提供交付文档初稿 | 需求单、变更记录 | 需求关联清单、文档初稿 |
| 构建/发布人员 | 执行构建与发布，提供制品原件和来源信息 | 构建任务、发布计划 | 制品原件、构建记录（分支、提交号、构建编号） |
| 质量人员 | 完成核验，出具核验结论 | 带标识的制品、文档清单 | 核验记录（校验值比对、齐套检查、版本一致性） |
| 配置管理员 | 维护命名规则与归档登记，组织审批 | 核验记录、归档对象清单 | 归档登记表、审批记录 |
| 交付负责人 | 输出交付清单，完成移交与签收 | 归档登记表 | 交付清单、签收记录 |
归档登记表建议包含以下字段：归档编号、制品名称、版本标识、来源标识（分支或提交号、构建编号、触发人、构建时间）、关联需求编号、校验值、文档清单、核验结论、审批人、入库时间、保留期限。交付清单字段与登记表对齐，另加交付对象、交付时间、接收方签收人，保证两份记录可以互相核对。
角色之间有两个交接点需要固定：构建/发布人员向质量人员移交制品和构建记录，质量人员向配置管理员移交核验记录。交接以记录为准，口头确认不作为归档依据。规模较小的团队可以由一人兼多个角色，但交接记录仍要分开留存，避免核验和审批由同一份记录承担。
当归档登记、审批流转和交付清单需要在系统内完成时，可以借助研发管理平台承载这些管理动作。ONES ALM 研发管理方案围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯；其数字线程连接需求、开发、测试、变更和发布等环节，需求变化时可沿关联关系分析受影响的任务、测试和交付内容，并保留过程追踪和审计依据。归档登记表、审批记录和交付清单的具体承载方式，需结合实际部署与所购模块确认。
一个发布包的归档示例
以下示例为演示情景，用于说明填写方式，不代表真实项目数据。
某产品发布 2.4.0 版本第二批次，发布包标识为 CRM-2.4.0-R02，对应构建产物 CRM-2.4.0-b0137。构建记录显示：分支 release/2.4，提交号 a1b2c3d，构建任务编号 B-2041，触发人张某，构建时间 3 月 12 日 14:20。关联需求为 REQ-318、REQ-322，均为本批次变更项。
核验过程分三步执行。第一步校验值比对：归档件与构建件哈希值一致，记录比对结果。第二步齐套检查：发布包内共 6 个文件，与文件清单逐项对应，无缺失、无多余。第三步版本一致性：发布说明和部署手册均标注 CRM-2.4.0-R02，与发布包标识一致。三项通过后，质量人员出具核验结论并附比对记录。
归档登记表填写示例如下：
| 字段 | 填写内容 |
|---|---|
| 归档编号 | AR-2024-0312-02 |
| 制品名称 | CRM 服务端发布包 |
| 版本标识 | CRM-2.4.0-R02 |
| 来源标识 | release/2.4，a1b2c3d，B-2041，张某，3 月 12 日 14:20 |
| 关联需求 | REQ-318、REQ-322 |
| 校验值 | 已比对一致（记录编号 V-0312-02） |
| 文档清单 | 发布说明、部署手册、验收记录 |
| 核验结论 | 通过 |
| 审批人 | 配置管理员李某 |
| 入库时间 | 3 月 12 日 17:00 |
| 保留期限 | 按合同约定，交付后 5 年 |
交付清单在登记表基础上填写：交付对象为客户运维团队，交付时间 3 月 13 日，交付内容为发布包、发布说明、部署手册、验收记录，接收方签收人王某。签收后本次归档闭环，后续按保留期限维护。
归档完成检查清单
判断一次归档是否真正完成，逐项核对下表。标注为阻断项的条目未通过时，归档不得标记完成。
| 检查项 | 通过标准 | 是否阻断 |
|---|---|---|
| 对象完整性 | 构建产物、发布包、交付文档三类对象均已纳入，数量与构建记录一致 | 是 |
| 版本一致性 | 制品、文档、登记表三处版本标识一致 | 是 |
| 来源可追溯 | 每个制品都有分支或提交号、构建编号、触发人和构建时间 | 是 |
| 文档齐套 | 文件清单逐项对应，发布说明、部署手册、验收记录齐全 | 是 |
| 校验值核验 | 归档件与构建件校验值比对一致，记录留存 | 是 |
| 审批与登记 | 审批记录完整，归档登记表字段无空缺 | 是 |
| 交付签收 | 交付清单已由接收方签收 | 是 |
| 保留策略 | 保留期限已登记，到期处置有审批路径 | 否，可在入库后补充 |
证据留存要求：核验记录、审批记录、归档登记表、交付签收记录四类材料随归档单元一并保存，保存期限不短于制品本身的保留期限。检查中发现的问题记录在案并明确整改责任人，整改完成后重新核对对应条目，不因单项通过而跳过整体复核。
常见问题
归档时制品数量与构建记录对不上，应该怎么处理？
先暂停本次归档，不进入标识和核验环节。回到构建记录逐项比对，确认差异是构建产物未全部采集，还是构建记录本身有遗漏或重复登记。补齐后重新核对数量，并在核验记录中写明差异原因和处理结果。数量一致是采集环节的完成标志，未达成时后续标识和核验都缺少可靠基础。
小团队一人兼多个角色，归档记录还能简化吗？
角色可以合并，记录不建议合并。核验记录和审批记录要分开留存，避免同一份记录同时承担核验结论和审批结论。可以由同一人先出具核验记录，再单独填写审批意见，两份记录各自留痕。这样在回溯时仍能看清核验依据和审批依据，不会因为人员少而失去可追溯性。
保留期限到期后，制品可以直接删除吗？
到期后先评估再处置。确认制品是否仍在交付合同服务期内、是否有合规留存要求、是否有未关闭的问题追溯需求。评估结论形成处置审批记录，审批通过后再执行删除或转存。保留策略条目在检查清单中列为非阻断项，可在入库后补充，但到期处置的审批路径要提前明确，避免误删仍在服务期内的制品。
归档登记和审批在系统里做，需要额外准备什么？
先确认登记表字段与系统内可记录的信息能对应，尤其是来源标识中的分支或提交号、构建编号、触发人和构建时间。ONES ALM 研发管理方案围绕需求、基线、版本和变更建立统一管理对象，数字线程连接需求、开发、测试、变更和发布等环节，可保留过程追踪和审计依据；归档登记表、审批记录和交付清单的具体承载方式需结合实际部署与所购模块确认。上线前用一次真实发布做试填，核对字段是否齐全。
交付清单和归档登记表内容不一致会有什么影响？
两份记录不一致时，接收方签收的交付内容与归档登记内容对不上，后续回溯无法判断实际交付了什么。交付清单字段与登记表对齐，另加交付对象、交付时间、接收方签收人。移交前由交付负责人逐项核对，发现差异以登记表为准修正清单，修正后再交接收方签收。
