研发制品归档是把构建产物、发布包、交付文档、测试与验收证据等可交付资产，按版本和交付批次收拢、命名、登记、校验并留存的过程。做好这件事的关键在于先划清归档范围与保留期限，再固定触发时点、责任人和校验标准。本文给出可直接执行的步骤、角色分工和完成检查清单，配置基线的建立与维护不在本文展开。
要点总览（TL;DR）
- 归档范围按可交付资产本体划定：构建产物与发布包、交付文档、测试与验收证据、部署与配置说明四类，分别确定归档粒度与保留期限，一个交付批次对应一套归档记录。
- 流程按触发、命名与元数据、入库、校验登记、异常补归档五步推进，每步明确输入、动作、输出与完成标志，触发点固定在版本发布、交付验收或里程碑关闭。
- 角色分工遵循谁产出谁提交、谁负责质量谁校验、谁对交付负责谁批准；配置管理员负责登记与完整性把关，对外交付版本建议增加一次归档评审。
- 归档是否完成以检查清单判定，对象完整性、命名与元数据、校验记录、审批确认任一项不满足即为阻断项，需补归档后复查。
- 归档登记、校验记录与确认单可挂到工作项和文档体系中，与版本、发布记录保持关联，抽查时能从批次记录直接追溯到制品和审批节点。
归档范围怎么划：哪些制品必须留、哪些不必留
归档范围按“可交付资产本体”来划，判断标准是：这份资产是否随某个版本或交付批次对外提供、是否用于证明交付质量、是否在后续维护或追溯中会被再次调取。满足其中一条，就应纳入归档；仅用于过程沟通、可随时再生成的中间材料，可以不进入正式归档。
建议把归档对象分成四类，分别确定粒度和保留期限：
| 类别 | 典型对象 | 归档粒度 | 保留期限设定思路 |
|---|---|---|---|
| 构建产物与发布包 | 安装包、镜像、可执行文件、补丁包 | 按版本号+构建标识，一个发布版本一套 | 不短于该版本的支持周期；对外交付版本按合同或合规要求延长 |
| 交付文档 | 需求说明、设计说明、用户手册、发布说明 | 按交付批次，与对应版本绑定 | 与产品生命周期一致，退役后按合规要求留存 |
| 测试与验收证据 | 测试报告、缺陷清单、验收记录、签字单 | 按批次+测试轮次 | 覆盖版本支持期，验收类证据按审计要求留存 |
| 部署与配置说明 | 部署手册、环境参数说明、配置清单 | 按批次+目标环境 | 与对应版本同周期，环境变更时同步更新归档 |
归档粒度建议与交付批次和版本绑定：一个批次对应一套归档记录，记录中列明该批次包含的全部制品及其版本。按个人目录或临时共享盘分散留存，会在人员变动或版本回溯时造成缺口，应尽量避免。
归档与配置基线是两件相邻但不同的事。配置基线关注哪些配置项在某一时刻被正式固定、变更如何受控，属于配置管理主题；本文处理的是资产本体的收拢、登记、校验与留存。两者在流程上衔接——基线确定“哪些版本是正式版本”，归档负责“把这些正式版本的资产完整保存下来”。
保留期限与清理规则应在范围划定阶段一并确定，至少写明：每类制品的最短保留期、到期后的清理审批人、清理前是否需要留档说明。清理规则缺失会导致存储无限膨胀，也会让“哪些还能删”变成无人敢决策的问题。
归档流程怎么跑：从触发到入库的操作步骤
归档流程按触发、命名与元数据、入库、校验登记、异常补归档五步推进。每一步都要有明确的输入、动作、输出和完成标志，否则流程容易停在“文件已上传、但没人确认”的状态。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 触发 | 版本发布通知、交付验收结论、里程碑关闭记录 | 由触发事件的负责人发起归档任务，明确批次号与范围 | 归档任务单，含批次、版本、对象清单 | 任务单已创建并指派到具体责任人 |
| 2. 命名与元数据 | 对象清单、版本号、构建标识 | 按统一规则重命名文件，填写元数据（版本、批次、构建标识、责任人、生成时间） | 命名规范、元数据完整的待归档文件集 | 抽查命名与元数据无缺失、无重名冲突 |
| 3. 入库 | 待归档文件集、存储位置规则 | 上传至指定归档位置，按批次目录组织 | 入库完成的制品集合 | 文件数量与清单一致，目录结构符合约定 |
| 4. 校验与登记 | 入库制品、对象清单 | 核对完整性（数量、大小、校验值），在归档登记表中逐项登记 | 校验记录、归档登记表 | 登记表与实物一一对应，校验结论为通过 |
| 5. 异常处理 | 校验不通过项 | 退回责任人补充或重新生成，补归档后重新校验 | 补归档记录、复检结论 | 全部异常项关闭，复检通过 |
触发时点要写进流程，而不是靠记忆。常见的三个触发点是：版本正式发布、交付验收通过、里程碑关闭。每个触发点对应一个明确的发起人，避免出现“发布做了、归档没人提”的情况。
命名与元数据规范是后续可检索的基础。建议命名至少包含产品名、版本号、批次号、构建标识和日期；元数据中补充责任人、生成环境和关联的发布记录编号。规则一旦确定，应在批次间保持一致，不因项目紧急而临时变通。
存储位置按“正式归档区”和“工作区”分开：工作区存放过程中间文件，正式归档区只接收通过校验的制品，并限制写入权限。这样能保证归档区的每一份文件都经过登记，减少误传和覆盖。
完整性校验至少覆盖三项：文件数量与清单一致、文件大小或校验值与生成记录一致、关键文档可正常打开。校验结果记入校验记录，作为后续复查的依据。校验不通过的制品退回责任人处理，补归档后重新走校验，不直接放入归档区。
在工具层面，归档任务单、校验记录和审批确认可以挂到工作项与文档管理中，让归档动作与版本、发布记录保持关联。ONES 当前方案覆盖需求、基线、版本、变更、测试与发布，围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯；测试用例、缺陷、版本和发布过程可以关联到需求链路中，便于在出现问题时定位影响范围。归档登记与校验记录放在同一套工作项和文档体系里，追溯时不必在多个系统间来回查找。具体承载方式和模板形态需结合团队现有流程确定。
角色与交付物怎么分：谁归档、谁校验、谁批准
角色分工遵循三条原则：谁产出谁提交，谁负责质量谁校验，谁对交付负责谁批准。配置管理员承担登记与完整性把关，是流程的枢纽角色，但不替代产出人提交材料。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 研发/构建负责人 | 提交构建产物与发布包，提供构建标识和生成记录 | 制品文件、构建记录、命名与元数据填写 |
| 测试负责人 | 提交测试报告、缺陷清单与验收证据，确认证据覆盖本轮测试范围 | 测试证据包、证据覆盖说明 |
| 交付或项目经理 | 发起归档任务，确认批次范围，组织异常处理，签署归档确认 | 归档任务单、归档确认单 |
| 配置管理员 | 维护命名与元数据规范，执行入库与完整性校验，登记归档台账 | 归档登记表、校验记录 |
评审与批准环节按交付影响设置。对内迭代版本可由项目经理确认即可关闭归档；对外交付或受监管的版本，建议增加一次归档评审，由配置管理员汇报校验结论、项目经理确认范围完整、质量负责人确认证据充分，三方确认后签署归档确认单。
交付物之间要能互相印证：归档登记表列出的每一项，应能在校验记录中找到对应结论；归档确认单引用的批次号，应与任务单和登记表一致。三者对不上，说明流程中有环节被跳过，需要回退补齐。
示例：一个版本交付批次的归档过程
以下为演示情景，用于说明流程如何落地，不代表任何具体企业的实际记录。
背景：某产品发布 V3.2 版本，交付批次号 B2024-07，包含安装包、用户手册、测试报告和部署手册四类制品，计划在发布当日完成归档。
第一步触发：版本发布通知发出后，项目经理创建归档任务单，写明批次 B2024-07、版本 V3.2、对象清单四类，指派构建负责人和测试负责人分别提交材料。
第二步命名与元数据：构建负责人将安装包命名为“产品名_V3.2_B2024-07_build0715”，元数据填写构建标识 build0715、生成时间、责任人；测试负责人将测试报告按轮次命名并附缺陷清单。抽查发现部署手册缺少目标环境说明，退回补充。
第三步入库：四类制品上传至正式归档区的 B2024-07 目录，按类别建立子目录，工作区中的中间文件不进入归档区。
第四步校验与登记：配置管理员核对文件数量与清单一致，安装包校验值与构建记录一致，测试报告可正常打开；在归档登记表中逐项登记，校验结论记为通过。
第五步异常处理：部署手册补充环境说明后重新提交，复检通过，异常项关闭。项目经理签署归档确认单，批次归档完成。
这个示例中可迁移的规律有三条：一是触发由发布事件驱动，任务单在发布当日创建；二是异常在入库后、确认前暴露并关闭，不带着缺口签署确认；三是登记表、校验记录、确认单使用同一批次号，保证三者可互相追溯。换到其他批次时，只需替换版本号、批次号和对象清单，流程结构保持不变。
完成检查：归档是否合格的核对项
归档是否完成，以检查清单逐项核对为准，不以“文件已上传”作为完成标志。以下清单中任一项不满足，即视为阻断项，需补归档后复查。
| 核对项 | 检查内容 | 通过标准 | 阻断条件 |
|---|---|---|---|
| 对象完整性 | 清单内每类制品是否齐全，数量是否一致 | 清单与实物一一对应，无缺项 | 任一类别缺失或数量不符 |
| 命名与元数据 | 命名是否符合规范，元数据字段是否填全 | 抽查全部关键制品，命名无冲突、元数据无空缺 | 存在重名、版本号或批次号错误 |
| 校验记录 | 是否完成数量、大小或校验值核对，结论是否记录 | 校验记录覆盖全部制品，结论为通过 | 无校验记录或存在未关闭的校验失败项 |
| 审批确认 | 归档确认单是否签署，签署人是否符合权限要求 | 确认单已签署，批次号与登记表一致 | 未签署或签署人越权 |
证据留存方面，归档登记表、校验记录和归档确认单应与制品本体一同保存，保存期限不短于对应版本的保留期。复查方式建议按批次抽查：每季度抽取若干批次，核对登记表与归档区实物是否一致，抽查结果记入归档台账，作为流程改进的依据。
当团队把归档任务、校验记录和确认单放在同一套工作项与文档体系中管理时，抽查可以直接从批次记录追溯到对应制品和审批节点。ONES 支持把标准流程、评审节点和交付物模板沉淀为可复用资产，使规范落到实际项目执行中；ONES Wiki 可用于沉淀项目文档与实践经验（该表述出自具体客户案例，不扩大为所有客户的统一效果）。归档检查清单本身也可以作为模板复用，新批次发起时直接套用，减少每次重新约定规则的成本。
常见问题
归档范围划定后，遇到临时补丁或热修复版本怎么处理？
热修复版本同样按交付批次归档，不因体量小或时间紧而跳过。建议在批次号上单独标识（如主批次加补丁序号），对象清单只列本次变更涉及的制品，但登记表要注明它对应的主版本和影响范围。补丁包、更新说明、回归测试记录三项应齐全，校验通过后并入正式归档区，与主版本记录建立关联，便于后续追溯“这个补丁修了什么、验证过什么”。
归档保留期限到期后，清理需要经过哪些确认？
清理规则应在范围划定阶段就写明：每类制品的最短保留期、到期后的清理审批人、清理前是否需要留档说明。执行时先由配置管理员列出到期清单，核对是否仍有在支持期内的版本或未关闭的审计、合同要求；确认无保留必要后，由审批人签署清理记录，清理记录本身按台账留存。涉及对外交付或受监管的版本，清理前建议再与交付负责人确认一次，避免删掉仍在履约期内的证据材料。
归档校验发现制品与构建记录不一致，应该重新生成还是补充说明？
先判断不一致的性质。如果是文件缺失、校验值不符或版本号错误，应退回责任人重新生成或重新提交，补归档后重新校验，不带着差异进入归档区。如果是记录本身填写有误（如构建标识笔误），可由责任人更正元数据并留下更正说明，配置管理员复核后放行。两种情况都要在异常记录中写明原因和处理方式，复检通过才关闭异常项，避免同类问题在后续批次重复出现。
团队规模较小、没有专职配置管理员时，归档职责怎么安排？
可以把配置管理员的登记与校验职责指派给固定的兼任人员，例如由项目经理或测试负责人承担，关键是职责明确到人、不随项目临时更换。此时更要依赖书面规则：命名与元数据规范、校验项、检查清单提前定好，兼任人员按清单执行即可，减少对个人经验的依赖。产出人提交、质量负责人校验、交付负责人批准这三条分工仍应保留，兼任不等于自己提交自己批准。
归档记录分散在多个系统里，抽查时怎么保证能追溯到制品本体？
核心是让批次号成为贯穿各环节的唯一索引：任务单、登记表、校验记录、确认单使用同一批次号，归档目录也按批次号组织。抽查时从批次号出发，先核对登记表与归档区实物是否一一对应，再检查校验记录和确认单是否齐全、签署人是否符合权限。把归档任务、校验记录和确认单放在同一套工作项与文档体系中管理，可以减少跨系统查找；ONES 支持把标准流程、评审节点和交付物模板沉淀为可复用资产，归档检查清单也可作为模板在新批次发起时套用。
