制品保留策略要解决的是“留什么、留多久、谁来清、怎么证明清对了”。做法可以拆成四步：先按制品类型和用途分级，再为每级写清保留期限与判定字段，然后把规则接到流水线和制品库的自动动作上，最后用检查清单验证执行效果。发布版本与合规证据长期保留，日常构建产物按窗口滚动清理，临时调试产物短期保留，是多数团队可用的起点。
要点总览（TL;DR）
- 制品保留策略按“分级—字段—执行—检查”四步落地：先按用途把制品分为发布版本、候选版本、日常构建、临时调试产物、依赖与基础镜像五级，再为每级确定期限与存储位置。
- 保留期限取回滚窗口、合规与审计要求、客户支持周期三者中的最长者作为下限，再结合存储成本调整；发布版本长期保留，日常构建按滚动窗口清理。
- 每条策略记录需包含制品标识、保留等级、创建时间、保留截止时间、清理动作和豁免标记，判定条件可按时间、版本标签或关联发布记录与工作项组合使用。
- 规则要接入流水线与制品库形成自动动作链：产出时写入元数据、按标签定级、定时计算到期清单、清理前通知、到期归档或删除、留存清理日志与归档清单。
- 策略是否生效看四点：所有制品类型都有对应等级、清理按计划发生且无误删、删除与归档记录可追溯、按季度评审并同步修订执行配置。
先定分级：哪些制品必须留、留多久
分级是保留策略的第一层判断。团队常见的失误是给所有制品设同一个期限：期限太短，回滚和审计时找不到包；期限太长，制品库被日常构建塞满，检索和备份成本上升。合理的做法是先按“用途”分五类，再给每类确定保留期限和存储位置。
保留期限的确定依据主要有三个：回滚窗口，即线上问题发生后团队需要回退到多久之前的版本；合规与审计要求，即所在行业或客户合同规定的证据留存年限；客户支持周期，即仍在维护期内的版本需要保留对应安装包和补丁包。三个依据取最长者作为下限，再结合存储成本调整。
| 等级 | 典型制品 | 保留期限 | 存储位置 | 责任人 |
|---|---|---|---|---|
| L1 发布版本 | 正式对外发布的安装包、镜像、补丁包 | 长期保留，覆盖产品支持周期与合同约定年限 | 正式制品库，独立于日常构建库 | 发布负责人 |
| L2 候选版本 | 发布候选包、灰度包、验收测试包 | 保留至下一正式版本发布后一个回滚窗口 | 正式制品库的候选目录 | 发布负责人 |
| L3 日常构建 | 主干与分支的持续集成产物 | 按滚动窗口保留，如最近若干天或最近若干次成功构建 | 日常构建库，可压缩存储 | 制品库管理员 |
| L4 临时调试产物 | 问题复现包、临时验证包、性能测试包 | 短期保留，问题关闭后进入清理队列 | 临时目录，单独标记 | 提交人 |
| L5 依赖与基础镜像 | 第三方依赖包、基础镜像、工具链镜像 | 跟随引用它的制品保留；无引用后按窗口清理 | 依赖仓库或镜像仓库 | 制品库管理员 |
这张表是模板，不是标准答案。团队应把“保留期限”一列替换成自己可执行的数值或规则，例如“最近30天”或“最近50次成功构建”，并注明依据来源，便于后续评审时解释为什么这样定。
写清规则：保留策略的字段与判定条件
分级结论要变成机器和人都能判定的规则，需要落到具体字段上。字段设计的目标是：任意一个制品进入制品库时，系统或管理员能根据字段直接算出它的保留截止时间，并知道到期后该做什么。
建议每条策略记录至少包含以下字段：
- 制品标识：名称、版本号、哈希值或制品库内的唯一路径，确保能唯一定位。
- 保留等级：对应L1至L5，决定后续期限与动作。
- 创建时间：制品入库时间，作为期限计算的起点。
- 保留截止时间：由创建时间加等级期限算出，或由发布记录、工作项关闭时间触发计算。
- 清理动作：到期后执行归档、删除或转冷存储，需明确动作类型。
- 豁免标记：标记该制品不参与自动清理，并记录豁免原因与审批人。
判定条件决定规则何时生效。常见三类：按时间判定，到期即进入清理队列；按版本标签判定，带正式发布标签的制品自动升为L1；按关联记录判定，制品关联的发布记录或工作项关闭后，临时产物进入清理倒计时。三类条件可以组合使用，例如“带发布标签且关联发布记录”的制品才允许升为L1。
豁免与例外需要单独设计标记方式。客户定制版本应标记客户名称与合同支持期；问题复现包应关联缺陷单号，缺陷关闭后自动取消豁免；审计取证包应标记审计项目与取证日期，保留期限按审计要求单独设定。豁免标记必须带审批人和到期复核时间，避免“永久豁免”变成无人清理的死角。
落地执行：从规则到自动清理与归档
规则写在文档里不会自动生效，需要接入流水线与制品库，形成一条可重复执行的动作链。这条链的输入是制品元数据、版本标签和发布记录；动作包括打标签、设置保留期、到期归档或删除、清理前通知；输出是清理日志、归档清单和可回溯的删除记录。
具体执行可以按以下顺序组织：
- 制品产出时写入元数据：流水线在构建完成后，把制品标识、创建时间、构建来源分支和关联工作项写入制品库元数据。
- 按标签自动定级：带正式发布标签的制品自动进入L1并设置长期保留；候选标签进入L2；无标签的日常构建默认进入L3。
- 定时任务计算到期清单：制品库按日或按周扫描，算出即将到期的制品，生成待清理清单。
- 清理前通知与缓冲期：向制品责任人发送到期通知，给出缓冲期，允许在缓冲期内申请豁免或延期。
- 执行归档或删除：缓冲期结束后，按策略执行归档到冷存储或删除，并记录操作人、时间、制品标识和动作结果。
- 输出记录并留存：清理日志与归档清单进入可查询的存储，作为回滚与审计的证据。
完成标志是：任意一个被清理的制品都能在日志中查到“何时、按哪条规则、由谁或哪个任务清理、清理前是否通知、是否被豁免”。缺少其中任何一项，策略就还停留在半自动状态。
在研发管理侧，制品与发布记录、需求和工作项的关联是判定条件能否成立的前提。ONES 的 ALM 方案覆盖需求、基线、版本、变更、测试与发布，可围绕需求、基线、版本和变更建立统一管理对象，支撑交付结果回溯；其 DevOps 方案可集成 Jenkins、GitLab CI 等流水线工具，同步流水线数据、执行状态和日志，并在项目、迭代、需求中可视化构建与发布过程。这些能力可以帮助团队把“制品对应哪个版本、哪次发布、哪个需求”记录清楚，为保留策略的判定条件提供关联依据。制品库层面的保留期设置与到期自动清理，需结合团队实际使用的制品库工具确认。
角色分工与交付物
保留策略无人维护，通常是因为职责没有落到具体角色和交付物上。建议至少明确五类角色，并让每个角色在策略生命周期中有明确的输入和输出。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 策略负责人 | 制定分级与期限规则，组织评审，处理豁免审批 | 保留策略文档、分级对照表、豁免审批记录 |
| 制品库管理员 | 配置自动清理任务，监控执行结果，处理误删与异常 | 清理任务配置、清理日志、异常处置记录 |
| 研发与测试 | 按规则打标签，提交临时产物时注明用途与关联工作项 | 制品标签、临时产物说明、豁免申请 |
| 发布与运维 | 确认发布版本进入L1，维护回滚窗口，提出期限调整需求 | 发布记录、回滚窗口说明、期限调整申请 |
| 审计或质量 | 抽查清理记录与归档清单，确认可追溯性满足要求 | 抽查报告、审计取证包清单 |
策略评审建议每季度一次，重点看三件事：清理任务是否按计划执行、豁免清单是否在增长、回滚窗口是否发生变化。发生重大发布节奏调整、客户合同变更或合规要求更新时，应触发临时评审。评审输出是策略文档的修订记录和下一周期的执行计划。
示例：一条发布制品的保留与清理过程
以下为演示情景，用于说明规则如何在一个制品上依次生效。
某产品团队在3月10日完成一次正式版本构建，流水线产出安装包并推送至制品库。构建任务自动写入元数据：制品标识为产品名加版本号，创建时间为3月10日，关联发布记录和需求条目。由于该制品带有正式发布标签，系统按规则将其定为L1，保留截止时间设为产品支持周期结束日，存储位置为正式制品库。
发布负责人当天核对发布记录，确认版本号、需求范围和测试结论一致，并在发布记录中登记该制品路径。这一步的判定点是：只有发布记录完整、测试结论通过的制品才允许保留L1标签，否则退回L2候选状态。
三个月后，团队需要排查一个线上问题，运维从正式制品库取出该版本重新部署，验证问题是否由后续版本引入。由于L1制品长期保留，回滚和复现都不需要临时找包。问题定位后，测试人员提交了一个复现包，标记为L4并关联缺陷单号，缺陷关闭后该复现包进入清理倒计时。
次年策略评审时，产品支持周期延长，策略负责人将该版本的保留截止时间同步延后，并在策略文档中记录变更原因。整个过程中，每个节点都有对应记录：构建元数据、发布记录、缺陷单、清理日志和评审修订记录，形成可追溯的链条。
完成检查：策略是否真正生效
策略是否生效，不能只看文档是否写完，要看制品库里的实际状态。以下检查清单可按季度逐项核对。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 规则覆盖度 | 所有制品类型都能对应到L1至L5中的某一级，无未分类制品 | 制品库分类统计、未分类制品清单 | 制品库管理员 |
| 期限可计算 | 每个制品都有保留截止时间或明确的期限计算规则 | 元数据抽样记录 | 策略负责人 |
| 清理按计划发生 | 清理任务按设定频率执行，无长期未运行的记录 | 清理任务运行日志 | 制品库管理员 |
| 无误删 | 抽查期内无L1制品被误删，误删事件均有处置记录 | 删除记录、异常处置单 | 制品库管理员 |
| 可追溯 | 任意一次删除或归档都能查到规则依据、操作时间和操作人 | 清理日志、归档清单 | 审计或质量 |
| 豁免受控 | 豁免制品均有原因、审批人和复核时间，无永久豁免 | 豁免清单 | 策略负责人 |
| 定期复核 | 策略按季度评审，修订有记录并同步到执行配置 | 评审纪要、修订记录 | 策略负责人 |
检查中发现的问题应回到对应环节修正：覆盖度不足就补分级，期限算不出就补字段，清理未执行就查任务配置，误删就收紧标签判定。每次复核后更新策略文档版本号，让执行配置与文档保持一致，策略才能持续有效。
常见问题
发布版本已经长期保留，为什么还要单独设候选版本等级？
候选版本处于“可能发布、也可能被替换”的状态，直接按发布版本长期保留会占用正式制品库空间，直接按日常构建清理又可能在回滚时找不到包。单独设L2等级，把保留期限绑定到“下一正式版本发布后一个回滚窗口”，既能覆盖灰度与验收阶段的问题复现，也能在正式版本稳定后自然释放空间。关键动作是发布负责人确认正式版本上线后，及时把候选目录中不再需要的包转入清理队列。
临时调试产物关联的缺陷长期未关闭，清理任务应该怎么处理？
这类制品不应因为缺陷未关闭就无限期保留。建议在豁免标记中同时记录缺陷单号和复核时间，到期后由制品库管理员通知提交人确认：仍需复现则续期并更新复核时间，已无复现价值则取消豁免、进入清理。缺陷关闭时系统自动取消豁免并启动清理倒计时。这样既保证问题可复现，也避免临时目录变成长期堆积区。
清理任务误删了需要保留的制品，应该怎么补救和预防？
补救分两步：先从归档清单或备份中恢复制品，再核查删除记录，确认是标签缺失、等级判定错误还是豁免未生效导致。预防上做三件事：清理前保留缓冲期并通知责任人；对L1制品设置删除保护，只允许归档不允许直接删除；每次误删事件登记处置记录，并在季度评审时回看是否需要在标签判定规则上收紧条件。
团队使用的制品库工具不支持按元数据自动定级，策略还能落地吗？
可以分阶段落地。先在半自动状态下运行：流水线产出时按命名规范写入版本标签和构建来源，制品库管理员按周导出制品清单，用脚本或表格算出到期清单，人工确认后执行归档或删除，并保留操作记录。等工具能力具备或完成替换后，再把定级和到期计算转为自动任务。关键是清理日志和归档清单从第一天起就完整留存，保证回滚与审计有据可查。
制品保留策略和研发配置基线管理是什么关系？
保留策略管的是可交付资产本体留多久、放在哪、到期怎么处置；配置基线管的是哪些配置项在某个时点被正式确认、后续变更如何受控。两者衔接点在发布版本：基线确认的版本应进入L1长期保留，基线变更后旧版本仍需按回滚窗口保留。本文只讨论制品本体的保留与清理，基线的建立与维护属于另一主题。
