制品保留策略的取舍，核心是让不同制品回答不同的追溯问题。按时间保留管“多久内必须可获取”，按版本数量保留管“每个制品留几个版本”，按发布基线保留管“哪些制品必须与已发布版本长期对应”。先按制品的可追溯责任分级，再为每类制品指定主策略与兜底策略，通常组合使用：基线定下限、时间定窗口、数量定上限。
要点总览（TL;DR）
- 三种保留策略回答不同问题：按时间保留管“多久内必须可获取”，按版本数量保留管“每个制品留几个版本”，按发布基线保留管“哪些制品必须与已发布版本长期对应”，判断依据分别是日历、版本序号和发布事件，不能互相替代。
- 取舍顺序是先按可追溯责任给制品分级：对外发布、受监管或需长期复现的制品以发布基线保留为主，迭代频繁的内部构建以版本数量保留为主，临时验证制品以时间保留为主，每类都要写明兜底规则。
- 组合使用时基线定下限、时间定窗口、数量定上限，并在配置中写明优先级：基线保留优先于数量规则，数量规则优先于时间规则，冲突时以更严格者为准。
- 规则由发布管理或配置管理负责人牵头制定，流水线或仓库自动执行清理，人工只处理临时保留、提前删除、超期保留三类例外，例外设有效期并到期回归常规规则。
- 落地前用试运行验证清理结果，重点确认基线制品未被误删，参数变更留记录，复核周期与责任人明确到岗位。
三种保留策略各自回答什么问题
保留策略的讨论容易混在一起，原因在于三种规则的计算依据完全不同。把它们分开看，才能判断某个制品该用哪一条规则兜底，哪一条规则只用于控制占用。
| 策略 | 回答的问题 | 判断依据 | 典型适用对象 |
|---|---|---|---|
| 按时间保留 | 多久内的制品必须可获取 | 制品产生时间或最后访问时间 | 临时验证、短期联调产生的制品 |
| 按版本数量保留 | 每个制品至少留几个版本 | 版本序号，保留最近 N 个 | 迭代频繁、体积较大的内部构建产物 |
| 按发布基线保留 | 哪些制品必须与发布一一对应、长期可追溯 | 发布事件或发布记录 | 对外发布、受监管或需长期复现的制品 |
三者的判断依据分别是日历、版本序号和发布事件，因此不能互相替代。时间窗口到期，不代表某个已发布版本的制品可以删除；版本数量足够，也不代表发布基线所需的那个特定版本仍在。理解这一点，后面的取舍才有基础。
按制品类型分级再选策略
取舍的起点是给制品分级，而不是先定参数。分级看四个维度：是否对外发布、是否受监管或合同约束、是否需要长期复现、体积与产生频率。前三个维度决定追溯责任，第四个维度决定存储压力。
| 制品类别 | 分级依据 | 主策略 | 兜底策略 |
|---|---|---|---|
| 对外发布制品 | 对外交付、受监管或合同约束、需长期复现 | 发布基线保留 | 基线制品不参与任何自动清理 |
| 内部构建产物 | 迭代频繁、体积较大、追溯周期有限 | 版本数量保留 | 保留最近若干版本，覆盖常规回滚跨度 |
| 临时验证制品 | 短期联调、验证用途、无对外责任 | 时间保留 | 设定最短窗口，到期自动清理 |
每类制品都要同时写明主策略和兜底规则。只写主策略容易留下缺口：例如内部构建只按数量保留，一旦某个构建恰好对应一次对外发布，数量规则可能把它清掉。兜底规则的作用就是在这种情况下把制品拉回保留范围。
分级结果要落到制品清单或仓库路径上，规则才能自动执行。按路径、标签或制品属性把每类制品映射到对应规则，避免依赖人工判断“这个制品属于哪一类”。映射关系本身也应纳入版本管理，规则调整时同步更新。
组合策略的参数怎么定
策略选定后，需要把三种规则组合成一套可配置的参数。每个参数都要有取值依据，并明确相互之间的优先级。
| 参数 | 取值依据 | 约束说明 |
|---|---|---|
| 时间窗口 | 回归验证周期、问题追溯周期、合同或监管要求的最短保存期 | 取三者中最长的要求作为下限 |
| 版本数量上限 | 单版本体积、仓库容量预算、回滚通常需要的版本跨度 | 上限应覆盖常规回滚跨度，再留出余量 |
| 发布基线范围 | 哪些发布事件必须留档 | 基线制品不参与自动清理，需单独标注 |
优先级需要写进配置，而不是靠口头约定：发布基线保留优先于数量规则和时间规则，数量规则优先于时间规则，冲突时以更严格者为准。举例来说，某个制品既在时间窗口内、又超出数量上限，此时按数量规则清理；若它同时属于某个发布基线，则基线规则生效，保留不动。
参数不是一次定终身。回归周期变化、仓库容量调整、监管要求更新，都会让原有取值失配。每次调整都要记录变更原因、生效时间和影响范围，并保留调整前的配置，便于回溯某次清理是否符合当时的规则。
角色分工与例外审批
规则能否持续运行，取决于角色是否清晰、例外是否有路径。建议按下表分工：
| 角色 | 职责 | 产出 |
|---|---|---|
| 发布管理或配置管理负责人 | 牵头制定保留规则，组织研发与运维确认参数 | 保留规则文档与参数配置表 |
| 流水线或仓库管理员 | 把规则配置到自动清理任务中，维护制品与规则的映射 | 可执行的清理配置 |
| 研发与运维 | 确认追溯需求，提出例外申请 | 例外申请单 |
| 审批人 | 批准临时保留、提前删除或超期保留 | 审批记录 |
日常清理由流水线或仓库自动执行，人工只处理例外。例外分三类：临时保留（某制品需在规则之外多留一段时间）、提前删除（确认无追溯需求后提前清理）、超期保留（超出既定窗口仍需保留）。每类例外都要有申请入口、审批人和有效期，到期后自动回到常规规则。
审计与复核按固定周期进行，例如每季度抽查一批已被清理的制品，确认是否仍有追溯需求；同时检查基线制品是否被误删。复核结果反馈到参数调整，形成闭环。责任人应明确到岗位，避免复核流于形式。
在工具承载上，ONES 当前方案覆盖需求、基线、版本、变更、测试与发布，围绕需求、基线、版本和变更建立统一管理对象，支撑交付结果回溯。发布基线与发布记录的关联可以在这里维护，例外申请与审批也可以借助评审节点和流程配置承载；制品本体层面的自动清理规则是否由 ONES 直接配置，需结合实际开通模块确认。
示例：一条产品线的保留规则
以下为演示情景，用于说明三种策略如何组合，不代表真实客户案例。某产品线同时存在对外发布、每日构建和临时联调分支三类制品。
- 对外发布制品：按发布基线保留。每个发布版本对应的制品与发布记录绑定，长期留存，不参与任何自动清理。
- 每日构建制品：按版本数量保留最近 30 个版本。单版本体积较大，30 个版本覆盖约一个月的回滚跨度，超出部分由流水线自动清理。
- 临时联调制品：按时间保留 14 天。联调结束后通常不再需要，到期自动清理。
一次例外处理：某次联调制品在第 12 天被确认需要作为问题复现材料保留三个月。研发提交临时保留申请，说明制品标识、保留原因和期望到期日；配置管理负责人审批通过后，该制品被加入例外清单，14 天规则对其暂停生效。三个月后例外到期，制品回到常规规则，若届时已超出时间窗口则被清理。审批记录与例外清单一并归档，供后续复核。
完成检查：策略是否可执行
用以下清单逐项核对，全部满足才说明保留策略可以落地：
- 每类制品都有明确的主策略与兜底策略，且已映射到制品清单或仓库路径。
- 时间窗口、版本上限、基线范围均有取值依据，依据可追溯到具体周期、容量预算或监管要求。
- 清理规则与基线保留的优先级已在配置中体现，冲突时以更严格者为准。
- 例外审批路径与责任人已明确，例外有有效期且到期自动回归常规规则。
- 已通过一次试运行验证清理结果符合预期，且未误删基线制品。
- 参数变更留有记录，复核周期与责任人已确定。
试运行建议先在非生产仓库或影子规则上执行，比对清理清单与预期清单的差异，确认无误后再全量启用。清单中的每一项都对应一个可观察的结果，便于在复核时判断策略是否仍然有效。
常见问题
制品既在时间窗口内又超出数量上限，还属于某个发布基线，清理时按哪条规则？
按优先级从高到低判断：发布基线保留优先于数量规则，数量规则优先于时间规则，冲突时以更严格者为准。因此这个制品属于发布基线，基线规则生效，保留不动，数量与时间规则对它都不适用。
要让这条判断可靠，需要把优先级写进清理配置，并在制品上单独标注基线归属，避免自动清理任务只读到数量或时间条件就执行删除。
临时保留申请到期后，制品会立刻被删除吗？
不会立刻删除。例外到期后，制品回到常规规则，是否清理取决于它当时是否满足清理条件：如果已超出时间窗口且不在基线范围内，才会被清理；如果仍在窗口内或属于发布基线，则继续保留。
建议在例外清单中记录期望到期日，到期前由责任人确认一次是否仍需保留，需要延长就重新走审批，避免到期后被动处理。
内部构建产物按版本数量保留，怎么避免清掉恰好对应某次对外发布的那个版本？
靠兜底规则。内部构建的主策略是版本数量保留，兜底规则是“一旦某个构建被纳入发布基线，就退出数量清理范围”。执行上需要在发布时把对应制品与发布记录绑定并打上基线标识，清理任务识别到该标识就跳过。
如果只配数量规则、不做基线标注，数量上限一旦覆盖到该版本，就可能被清掉。因此分级表里每类制品都要同时写主策略和兜底策略。
时间窗口和版本数量上限应该先定哪个？
先定时间窗口，再定版本数量上限。时间窗口的下限来自回归验证周期、问题追溯周期和合同或监管要求的最短保存期，取三者中最长的要求；版本数量上限则在这个窗口内，按单版本体积、仓库容量预算和常规回滚跨度来确定。
顺序反过来容易出现数量上限过小、窗口内版本已被清空的情况。两个参数定完后，再确认基线范围，把不参与自动清理的制品单独标注出来。
保留规则定好后，怎么判断它真的在按预期执行？
做一次试运行：在非生产仓库或影子规则上执行清理，把实际清理清单与预期清单逐项比对，重点检查基线制品是否被误删、窗口内的制品是否被提前清理。
试运行通过后全量启用，并把复核纳入固定周期，例如每季度抽查一批已清理制品是否仍有追溯需求。复核结果反馈到参数调整，参数变更记录原因、生效时间和影响范围，形成闭环。
