制品保留策略示例要解决的是把“制品该留多久”变成可执行规则：先按发布包、构建制品、交付文档、临时验证包分类，再为每类写明保留期限、到期动作、责任人和留存证据。下面给出一份已填写的四列示例表，并逐项解释取值依据与调整方法。表中的期限与规则均为演示设定，企业需结合自身合规要求、存储成本和发布节奏调整。
要点总览（TL;DR）
- 示例表以“制品类别—保留期限—到期动作—责任人与证据”为核心结构，按对外发布包、内部构建制品、临时验证包、交付文档、版本标识与来源记录五类分级设定。
- 期限设定依据合规与合同要求、问题回溯需求和存储成本三条线索，到期动作区分直接清理、归档冷存、随版本归档三种处理方式。
- 填写顺序固定为“先分类、再定期限、后定动作与责任人”，保留时长可按发布频率与回溯窗口反推，规则应挂到版本标识和交付清单上。
- 表中期限与审批层级均为演示值，正式制度需经评审；组织配置基线管理、制品仓库底层存储实现和行业强制留存要求需另行处理。
示例要解决什么问题：保留策略该写到什么颗粒度
很多团队在制品管理上遇到的困扰，是规则停留在口头约定：发布包放在仓库里没人清理，临时验证包越积越多，出了问题想回溯某个版本，却找不到对应的构建记录。保留策略示例的目标，就是把这类模糊判断转成一条条可执行的规则——什么制品、留多久、到期怎么处理、谁负责、留下什么证据。
一份可执行的保留策略，覆盖对象至少包括四类：构建制品（每次构建产出的包）、发布包（对外或对下游交付的版本）、交付文档（版本说明、交付清单、验收记录）、版本标识与来源记录（版本号、构建来源、提交信息）。这四类对象的保留需求差异明显，混在一起定规则容易一刀切。
颗粒度上，建议按制品类别分级设定，而非逐文件设定。逐文件设定看似精细，实际维护成本高，一旦制品数量增长，规则很快失效。按类别分级后，每类给出一条期限和动作，再补充少量例外条款，既好执行也好复核。判断颗粒度是否合适的标准很简单：一个新加入的构建负责人，能否只看这张表就判断自己产出的包该不该清理。
需要说明的是，本文示例为演示情景，期限取值、审批层级均为示意，不构成企业制度建议。
完整示例：一份四列制品保留策略表
下表是一份已填写的示例，核心结构为“制品类别—保留期限—清理与归档动作—责任人与证据”，并补充典型对象与留存证据两列便于落地。所有期限均为演示值。
| 制品类别 | 典型对象 | 保留期限（演示） | 到期动作 | 责任人 | 留存证据 |
|---|---|---|---|---|---|
| 对外发布包 | 正式版本安装包、对外交付的镜像或压缩包 | 长期保留，至少覆盖该版本的支持周期 | 转入归档存储，保留版本标识与校验值；不直接删除 | 发布负责人 | 发布记录、版本标识、校验值、归档审批单 |
| 内部构建制品 | 日常构建产出的中间包、候选版本包 | 90 天 | 到期后清理，保留最近一次成功构建的包 | 构建负责人 | 构建记录、清理审批记录 |
| 临时验证包 | 联调、验证、问题复现用的临时包 | 14 天 | 到期直接清理，验证结论转入问题记录或交付文档 | 构建负责人 | 验证结论记录、清理日志 |
| 交付文档 | 版本说明、交付清单、验收记录 | 与对应版本同周期保留 | 随版本归档，不单独清理 | 交付负责人 | 文档版本号、关联版本标识 |
| 版本标识与来源记录 | 版本号、构建来源、提交信息、构建参数 | 与所指向制品同周期保留 | 随制品归档或清理同步处理，保留元数据 | 发布负责人 | 版本标识清单、来源记录快照 |
这张表可以直接作为填写模板：把“典型对象”换成团队实际制品名称，把演示期限换成经评审的期限，把责任人换成具体角色。表中每一行都对应一个可判断的动作，避免出现“视情况保留”这类无法执行的表述。
逐项解释：每一行规则为什么这样定
保留期限的设定依据主要有三条：合规与合同要求、问题回溯需求、存储成本。对外发布包通常受合同或行业要求约束，期限最长，且到期后选择归档而非删除；内部构建制品的回溯窗口一般集中在最近几个版本，90 天是演示值，实际可按发布频率调整；临时验证包的价值在验证结论，结论记录后包本身即可清理，因此期限最短。
到期动作需要区分三种处理方式。直接清理适用于临时验证包这类可重建、结论已留存的制品；归档冷存适用于对外发布包，保留可恢复能力但降低存储成本；转交付清单留存适用于交付文档，文档本身随版本走，不需要单独设定清理动作。三种动作对应不同的审批要求，直接清理可简化审批，归档与删除发布包应保留审批记录。
责任人的划分按制品生命周期中的关键角色确定：构建负责人对自己产出的构建制品和临时包负责，发布负责人对对外发布包和版本标识负责，交付负责人对交付文档负责。责任到角色而非到个人，人员变动时规则仍然有效。
证据字段的作用是证明清理经过审批且可追溯。没有证据，清理动作无法审计，出现问题时也难以判断是正常清理还是误删。版本标识与来源记录需要与制品同步保留，原因在于制品本身可以重建，但“这个包由哪次提交、哪套参数构建而来”的信息一旦丢失，重建就失去依据。
在工具层面，制品、版本标识与构建来源如果分散在不同系统中，保留规则很难统一执行。ONES 支持在研发流程中关联工作项、版本与交付记录，团队可以把保留策略中的版本标识、来源记录和审批动作挂到同一处管理，减少清理时逐系统核对的成本。这一衔接适用于希望把保留规则与版本管理放在同一流程中的团队。
可迁移规律：换一套制品体系怎么改这张表
填写顺序建议固定为“先分类、再定期限、后定动作与责任人”。分类依据是制品的用途和可重建性：可重建且结论已留存的，期限短、动作直接；不可重建或对外承诺的，期限长、动作偏归档。顺序颠倒容易出现先拍期限再找理由的情况。
保留时长可以按发布频率和回溯窗口反推。例如每月发布一次、需要回溯最近六个版本的团队，内部构建制品的保留期至少覆盖六个月；发布频率高的团队可以缩短单次保留期，改为按版本数量保留。反推的好处是期限有业务依据，评审时容易达成一致。
清理动作要与审批流程对应。可以直接清理的类别，审批可以简化到构建负责人确认；涉及归档或删除对外发布包的，应保留发布负责人审批。把动作和审批绑定后，规则执行时不需要每次重新讨论。
保留规则应挂到版本标识和交付清单上，而不是只写在制度文档里。制品入库时带上版本标识，清理时按标识核对，交付清单则作为对外承诺的凭证同步归档。这样规则跟着制品走，换团队、换仓库都不容易失效。
最后要建立定期复核机制。建议每季度或每次重大发布节奏变化后复核一次：检查是否有类别长期未触发清理、是否有新制品类型未纳入表格、存储成本是否超出预期。复核结论直接更新表格版本，并保留变更记录。
适用边界：哪些情况需要另做处理
本文示例聚焦制品保留策略的填写方法，以下情形需要另行处理：
- 组织配置基线的管理不在本文范围，该部分属于研发配置与基线管理的内容，基线保留规则应与制品保留策略分开制定。
- 制品仓库底层的开发与存储实现不在本文讨论范围，涉及存储分层、去重等技术方案时需由平台团队另行设计。
- 涉及行业强制留存要求时，需另行核对适用的合规条款，示例中的演示期限不能替代合规评估结论。
- 示例期限为演示值，不能直接作为企业制度发布，正式制度应经过评审并明确生效日期与版本。
- 跨团队共享制品的保留责任需要额外约定，例如上游团队产出的包被下游团队长期引用时，应由双方明确保留期限与清理通知机制。
在上述边界之外，这张四列示例表可以作为大多数研发团队起草保留策略的起点，按自身制品类型、发布节奏和合规要求逐行替换即可。
常见问题
制品保留策略里的期限，应该由谁拍板？
期限通常由三类角色共同确认：发布负责人提供对外承诺与合同要求，平台或构建负责人提供存储成本与可重建性判断，合规或质量角色提供行业留存要求。示例中的期限只是演示值，正式取值建议形成一次评审记录，写明依据和生效日期，后续调整时沿用同一评审路径。
临时验证包到期直接清理，会不会影响问题复现？
关键在于验证结论是否已经留存。示例把临时验证包设为 14 天并到期直接清理，前提是验证结论、复现步骤和关联问题记录已经写入问题记录或交付文档。如果某类验证包本身难以重建、复现成本高，可以单独列为一行，延长保留期或改为归档处理，不必强行套用最短期限。
上游团队产出的包被下游长期引用，保留责任怎么分？
跨团队共享制品需要在保留策略之外补充约定：由上游团队明确该制品的保留期限和清理通知方式，下游团队在引用时登记依赖关系。清理前按约定提前通知，或把被引用的版本转为归档保留。示例表本身不覆盖这类跨团队约定，建议单独形成一份共享制品清单。
保留策略制定后，怎么判断它是否真的在执行？
可以从三个可观察点检查：一是各类别是否按期限触发了清理或归档，长期没有动作的类别往往意味着规则未落地；二是清理审批记录和归档记录是否完整，能否对应到具体制品和版本标识；三是存储占用是否随发布节奏合理变化。建议每季度或发布节奏变化后复核一次，把结论更新到表格的新版本并保留变更记录。
版本标识和来源记录为什么不能随制品一起删掉？
制品本身通常可以重建，但“这个包由哪次提交、哪套参数构建而来”的信息一旦丢失，重建就失去依据，问题回溯和交付核对都会受影响。示例把版本标识与来源记录设为与所指向制品同周期保留，清理时同步处理元数据，目的就是让制品的存在与来源始终可对应。
