制品保留策略要落地，关键是把“留多久、放哪里、什么时候清、谁批准”写成一张可执行的表。下面给出一份按制品类型和发布级别分档的填写示例，覆盖构建产物、发布包、镜像和交付文档，并逐项解释取值依据。示例为演示情景，假设条件均为设定值，不涉及真实客户与实测数据。
要点总览（TL;DR）
- 示例的核心是一张按制品类型和发布级别分档的保留表，每行写明保留时长、保留位置、清理触发条件、审批人和到期处置动作。
- 保留时长按可重建性与追溯必要性设定：日常构建产物14天，正式发布包24个月，交付文档36个月。
- 清理触发条件与发布节奏和商务节点挂钩，例如镜像以版本下线并完成替换验证为触发点，客户定制版本以合同期满为触发点。
- 换团队使用时，按发布频率调整档位密度，合规变化集中在发布包与交付文档两行，多产品线采用公共档位加附加档位结构。
- 示例的团队规模、发布节奏与合规强度均为演示设定，工具能力与存储实现需另行查证。
示例要解决什么问题：保留策略的填写目标
这份示例要回答一个具体问题：团队里每一类可交付资产，应该保留多长时间、存放在哪个层级、在什么条件下可以清理、由谁确认处置。很多团队的保留规则散落在口头约定或个人目录里，结果是发布包长期堆积占用存储，而真正需要追溯的历史版本又找不到。示例的目标是把这些判断固化成一张表，让每类制品都有明确的保留时长与处置方式。
示例覆盖的制品范围限定为可交付资产本体，包括：
- 构建产物：每次流水线构建生成的中间包，数量大、可重建；
- 发布包：对外或对客户交付的正式版本安装包、补丁包；
- 镜像：容器镜像及其标签版本；
- 交付文档：随版本交付的说明文档、验收材料、发布说明。
组织配置基线、基线管理与制品仓库的底层存储实现不在本文范围内。示例中的团队规模、发布节奏、合规强度均为演示设定，读者应把它们替换为自己团队的真实条件后再使用。
完整示例：一张填好的制品保留策略表
示例假设一个约30人的产品研发团队，采用双周迭代、每月一次正式发布，所处行业有中等强度的合规留档要求，制品仓库按“热存储—冷存储—归档”三层组织。在这一假设下，填好的保留策略表如下。
| 制品类型 | 发布级别 | 保留时长 | 保留位置 | 清理触发条件 | 审批人 | 到期处置动作 |
|---|---|---|---|---|---|---|
| 构建产物 | 日常构建 | 14天 | 热存储 | 超过14天且非发布关联构建 | 构建负责人 | 直接删除 |
| 构建产物 | 发布关联构建 | 与对应发布包同期 | 热存储转冷存储 | 随发布包到期一并处理 | 发布负责人 | 随发布包归档或删除 |
| 发布包 | 正式发布 | 24个月 | 冷存储 | 满24个月且无在途追溯需求 | 发布负责人＋质量负责人 | 转归档，保留清单记录 |
| 发布包 | 客户定制版本 | 合同期满后12个月 | 冷存储 | 合同期满且客户无回溯请求 | 交付负责人＋法务确认 | 归档，保留交付记录 |
| 镜像 | 生产在用版本 | 在用期间持续保留 | 热存储 | 版本下线并完成替换验证后 | 运维负责人 | 转冷存储，保留90天后删除 |
| 镜像 | 历史版本 | 12个月 | 冷存储 | 超过12个月且无回滚需求 | 运维负责人 | 删除 |
| 交付文档 | 正式发布 | 36个月 | 文档库 | 满36个月且合规留档期已过 | 质量负责人 | 归档，保留索引 |
| 交付文档 | 内部草稿 | 6个月 | 文档库 | 对应版本发布后满6个月 | 文档责任人 | 删除 |
这张表可以直接作为模板使用：把“发布级别”一列替换为团队自己的版本分类，把时长和审批人按实际条件调整，其余结构保持不变。表中每个单元格都对应一个可执行动作，避免出现“视情况保留”这类无法判断的表述。
逐项解释：每个字段为什么这样填
保留时长的设定依据是“可重建性”与“追溯必要性”两个维度。构建产物可以随时从代码重新构建，因此日常构建只保留14天，覆盖近几个迭代的排障需要即可；发布关联构建与发布包绑定，单独设定时长会造成两份记录不一致，所以让它随发布包同期处理。发布包和交付文档承担对外交付与合规追溯职责，时长明显更长，正式发布包24个月、交付文档36个月，后者更长是因为文档常被用于事后审计与验收复核。
清理触发条件与发布节奏挂钩，而不是简单按自然日到期。镜像的清理以“版本下线并完成替换验证”为触发点，确保清理动作发生在业务风险解除之后；客户定制版本以“合同期满”为触发点，把商务约束纳入技术清理流程。这样设定的好处是清理动作有明确的前置事件，执行人不需要反复确认业务状态。
责任人与审批链按“谁产生、谁负责，谁受影响、谁确认”设置。构建产物由构建负责人处置，影响面小，单人确认即可；发布包涉及对外交付，采用发布负责人与质量负责人双签；客户定制版本额外引入法务确认，因为涉及合同义务。审批链的长度与制品的影响范围成正比，避免所有制品都走同一条长流程导致执行拖延。
归档与删除的区分标准是“是否仍需可检索”。归档保留清单记录和索引，制品本体转入低成本存储，满足事后查询与审计需要；删除则彻底移除，仅适用于可重建或已无追溯价值的制品。示例中正式发布包到期后选择归档而非删除，正是因为其清单记录本身具有追溯价值。
策略表制定完成后，落地环节需要让每次发布、每个交付物在协作系统中有对应记录和评审节点。ONES 的方案围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯，并可将评审节点、交付物模板沉淀为可复用资产；在示例场景中，发布包的审批与归档确认可以依托这类记录完成状态流转，具体配置需结合团队实际实施确认。
可迁移规律：换一个团队怎么改这张表
发布频率直接影响保留档位的密度。每周多次发布的团队，日常构建产物的保留天数可以压缩到7天以内，同时把发布包的档位从“每次发布”改为“每个对外版本”，避免档位数量随发布次数线性膨胀。发布频率低的团队则相反，可以把构建产物保留期适当延长，减少因排障需要而临时找回制品的次数。
合规要求变化时，调整应集中在发布包与交付文档两行。合规留档期延长，就同步加长这两类制品的保留时长，并把到期处置从“删除”改为“归档”；合规要求放宽，可以缩短时长，但建议保留一个缓冲期，避免政策反复导致历史记录缺失。调整时同步更新审批人，确保新时长有对应的确认责任。
从单团队扩展到多产品线时，建议采用“公共档位＋产品线附加档位”的结构：公共档位定义所有产品线都必须遵守的最低保留要求，各产品线在此基础上按自身客户合同、行业规范追加更长的保留期。这样既保证底线一致，又允许差异化管理，避免一张表被反复修改。
策略需要定期复核，建议每半年一次，复核内容包括：到期清理是否按计划执行、是否有制品因追溯需求被临时延长、审批链是否仍与实际角色匹配。复核结果形成简短的调整记录，作为下一版策略表的输入。
适用边界：示例不能直接照搬的地方
示例的时长、审批人和存储层级都建立在“30人团队、双周迭代、月度发布、中等合规强度”这一组假设之上。团队规模显著更大、发布节奏更快或所处行业合规要求更严时，应优先调整发布包与交付文档两行，再复核构建产物与镜像的清理触发条件是否仍然成立。
本文不涉及组织配置基线与基线管理，也不讨论制品仓库的底层开发与存储实现。示例中的“热存储、冷存储、归档”是管理层面的分层描述，具体如何映射到实际存储系统，需要结合团队已有的仓库设施确定。
示例不包含具体工具的能力、版本与价格信息。若需要确认某工具是否支持保留时长配置、到期自动清理或删除审批流程，应另行查证其官方资料，不宜以本文示例作为工具选型依据。
常见问题
保留时长到期后，应该删除还是归档？
判断标准是这份制品是否仍需可检索。归档保留清单记录和索引，制品本体转入低成本存储，适合承担对外交付与合规追溯职责的发布包和交付文档；删除彻底移除本体，适合可重建的日常构建产物或已无追溯价值的历史镜像。示例中正式发布包到期后选择归档，原因是清单记录本身具有追溯价值。
发布频率变化后，表里哪些行需要优先调整？
优先调整构建产物和镜像两类。发布频率提高时，日常构建产物的保留天数可以压缩，发布包档位从“每次发布”改为“每个对外版本”，避免档位数量随发布次数膨胀；发布频率降低时，可适当延长构建产物保留期，减少临时找回制品的次数。发布包与交付文档的时长由合规要求决定，不随发布频率同步变动。
多产品线共用一份策略表时，如何处理各产品线的差异？
建议采用“公共档位＋产品线附加档位”的结构。公共档位定义所有产品线都必须遵守的最低保留要求，各产品线按自身客户合同和行业规范追加更长的保留期。这样底线一致，差异化管理有明确位置，避免一张表被反复修改后失去约束力。
策略表制定后，如何确认到期清理真的在执行？
建议每半年复核一次，复核内容包括到期清理是否按计划执行、是否有制品因追溯需求被临时延长、审批链是否仍与实际角色匹配。复核结果形成简短的调整记录，作为下一版策略表的输入。若团队使用协作系统登记发布与交付物，可依托其中的状态记录核对清理动作是否完成。
示例中的热存储、冷存储、归档如何对应到实际仓库？
示例中的三层是管理层面的分层描述，用于区分访问频率与成本，具体映射到实际存储系统需要结合团队已有的仓库设施确定。本文不讨论制品仓库的底层开发与存储实现，也不涉及组织配置基线与基线管理，这两部分应另行规划。
