制品保留策略要解决的核心问题，是让该留的版本留得住、该清的版本清得掉。按时间、按版本数量、按发布基线这三种规则回答的其实是不同问题：多久之内还能找回旧制品、每个制品最多留几份、哪些制品必须与某次发布绑定留存。本文按场景与边界逐一比较三种策略，并给出组合取舍的判断顺序。
要点总览（TL;DR）
- 按时间保留回答“多久之内还能找回旧制品”，适合有明确合规或回溯期限、发布节奏稳定的团队；代价是期限内制品数量不可控，期限外的重要版本会丢失。
- 按版本数量保留回答“每个制品最多留几份”，适合迭代频繁、单制品版本多、存储成本敏感的团队；它给仓库体积设定可预期上限，但版本份数与时间跨度并不等价。
- 按发布基线保留回答“哪些制品必须与某次发布绑定留存”，适合需要长期复现线上版本、支持审计与回滚的交付场景；它回溯能力最强，但依赖发布流程规范执行。
- 实际取舍通常以发布基线为底线，再用时间或数量规则清理基线之外的普通制品，并按交付物、依赖包、临时构建产物区分规则。
- 工具选型时核对三点：保留规则能否按仓库或制品类型配置、基线制品能否排除在清理规则外、清理前能否预览影响范围。
三种保留策略各自解决什么问题
三种策略的判断对象不同，因此它们之间是叠加关系，选一种并不排斥另一种。理解这一点，是设计保留规则的前提。
按时间保留的判断依据是制品的存活时长：从制品产生或最后一次被访问起算，超过设定期限即进入清理范围。它回答的是“多久之内还能找回旧制品”，把留存决策交给日历。
按版本数量保留的判断依据是同一制品保留的版本份数：每个制品只保留最近若干版本，更早的版本被清理。它回答的是“每个制品最多留几份”，把留存决策交给版本计数。
按发布基线保留的判断依据是制品与发布动作的绑定关系：凡是被纳入某次发布基线的制品，无论产生多久、是第几个版本，都必须留存。它回答的是“哪些制品必须与某次发布绑定留存”，把留存决策交给发布流程。
三者可以同时生效。常见做法是以发布基线划定不可清理的底线，再用时间或数量规则处理基线之外的普通制品。这样既保证关键版本可复现，又让日常构建产物有明确的退出机制。
同口径差异对照：时间、数量与基线三种策略怎么比
把三种策略放到同一组维度上比较，差异会更清楚。下表按适用版本节奏、回溯粒度、存储增长方式、与发布流程的耦合度、管理维护成本五个维度展开。
| 对照维度 | 按时间保留 | 按版本数量保留 | 按发布基线保留 |
|---|---|---|---|
| 适用版本节奏 | 发布节奏相对稳定，可按自然周期估算留存 | 迭代频繁，单制品版本产出多 | 发布次数有限，每次发布有明确范围 |
| 回溯粒度 | 按时间跨度回溯，期限内均可找回 | 按版本序号回溯，只能回到最近若干版 | 按发布批次回溯，可精确复现某次发布 |
| 存储增长方式 | 随发布密度线性增长，期限内不可控 | 总量受版本数上限约束，增长可预期 | 随基线数量增长，单条基线内制品完整保留 |
| 与发布流程的耦合度 | 低，独立于发布动作运行 | 低，独立于发布动作运行 | 高，依赖发布时正确标记基线 |
| 管理维护成本 | 低，设定期限后基本无需干预 | 低，设定份数后自动执行 | 较高，需要发布流程规范与基线治理 |
从表中可以看出，按时间与按数量两种策略的管理成本低，但回溯能力受期限或份数限制；按发布基线的回溯能力最强，代价是对发布流程规范性的依赖。存储敏感且迭代快的团队，按数量保留能给出可预期的仓库体积上限；有明确合规期限的团队，按时间保留更容易向审计方解释留存口径。
需要说明的是，不同制品管理工具对这三类规则的支持程度、配置粒度和执行机制存在差异，具体能力应以实际选型时的产品资料为准。
按时间保留适合什么场景，边界在哪里
按时间保留适合对“留存多久”有明确答案的团队。当合规制度、客户合同或内部审计要求规定制品须保留若干个月或若干年时，按时间设置规则最直接，规则本身也容易向外部说明。
它同样适合发布节奏相对稳定的团队。例如按月或按双周固定发布的产品线，可以按自然周期估算存储需求，把保留期限设为覆盖最近若干个发布周期的长度，既满足回溯需要，又不必逐版本管理。
边界主要有两条。其一，期限内的制品数量不可控：发布越密集，期限内累积的制品越多，存储增长会超出预期，需要配合容量监控。其二，期限外仍需复现的历史版本会丢失：如果某次重要发布发生在期限之外，而它又没有单独的留存安排，清理后就无法找回。因此按时间保留通常需要与发布基线配合，把重要发布排除在时间清理之外。
按版本数量保留适合什么场景，边界在哪里
按版本数量保留适合迭代频繁、单制品版本产出多的团队。依赖包、内部组件库、频繁构建的服务镜像都属于这类对象：每个制品每周可能产生多个版本，但实际需要回退的通常只是最近几个。
它也适合存储成本敏感、需要给仓库体积设定上限的团队。版本份数是一个可预期的数字，乘以制品总数就能估算存储规模，便于做容量规划。
边界在于版本数量与时间跨度并不等价。低频制品可能长期占用名额：一个半年才更新一次的制品，保留最近五个版本意味着跨越很长时间，实际价值有限。高频制品则可能过早清理：一天构建十次的制品，保留最近五个版本只覆盖半天，一旦需要回溯更早的构建就会缺失。此外，按数量清理与合规期限要求可能冲突，若某类制品有法定留存期，需要单独校验并排除在数量规则之外。
按发布基线保留适合什么场景，边界在哪里
按发布基线保留适合需要长期复现线上版本的交付场景。当线上出现问题需要定位时，团队要能取回与当时发布完全一致的制品集合，包括主程序、依赖和配置相关产物。把留存决策绑定到发布动作上，可以保证每次发布都有一套完整、可追溯的制品。
它同样适合有审计与问题追溯要求的行业交付。发布基线记录了“哪次发布用了哪些制品”，配合变更与测试记录，可以回答审计方关于版本来源和交付内容的询问。
边界有两条。其一，它依赖发布流程规范执行：如果某次发布没有正确标记基线，相关制品就不会被纳入留存范围，后续清理时可能被误删。其二，基线数量会随时间增长，每条基线都完整保留制品，长期看存储压力仍然存在，需要配套清理规则，例如只对最近若干条基线做完整保留、更早基线保留清单与关键制品。
如何组合取舍：以基线为底线叠加清理规则
实际工作中很少只用一种策略。可执行的保留规则通常按以下顺序设计：
- 先确定必须长期留存的发布基线范围。明确哪些发布需要完整复现，例如对外正式版本、监管要求覆盖的版本、重大客户交付版本，把这些发布纳入基线留存，并规定基线制品不受其他清理规则影响。
- 再选择时间或数量规则清理非基线制品。对基线之外的普通构建产物，按团队特征二选一：回溯期限明确就用时间规则，存储敏感、只需回退最近版本就用数量规则。
- 按制品类型区分策略。交付物与正式发布制品以基线留存为主；依赖包、内部组件适合按版本数量控制；临时构建产物、测试中间产物可以设置更短的时间期限，甚至不纳入长期留存。
- 规则上线后定期核对。每隔一个周期检查存储增长曲线与实际的回溯请求，判断期限是否过长、份数是否过少、基线是否被正确标记，并据此调整参数。
这套顺序的关键在于基线先行：先划出不可清理的底线，再让时间或数量规则在底线之外发挥作用，避免出现“重要版本被数量规则清掉”的情况。
在工具层面落地这套规则时，可以把发布基线与制品留存衔接起来。ONES 当前方案覆盖需求、基线、版本、变更、测试与发布，围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯；测试用例、缺陷、版本和发布过程关联到需求链路后，出现问题时可定位影响范围。这些能力为“哪些制品属于哪次发布”提供了追溯依据，保留规则的具体配置方式则以实际产品资料为准。
适配场景与选择建议
按团队特征可以对号入座：
- 合规期限明确、发布节奏稳定的团队，优先按时间保留。期限直接对应制度要求，规则简单、易于解释，配合基线排除重要发布即可。
- 迭代快、存储成本敏感的团队，优先按版本数量保留。用版本份数给仓库体积设定上限，同时对有法定留存要求的制品单独排除。
- 需要长期复现与审计的交付团队，以发布基线为底线。先保证每次正式发布可完整取回，再用时间或数量规则处理基线之外的制品。
- 同时具备多种特征的团队，按制品类型拆分规则：交付物走基线，依赖包走数量，临时产物走短周期时间规则。
在制品管理工具中配置这些规则前，建议核对以下能力点：保留规则能否按仓库或制品类型分别配置；基线制品能否被排除在清理规则之外；清理执行前能否预览受影响的制品范围，避免误删。这些核对点用于评估工具是否支撑上述组合方案，具体支持情况需以产品实际资料为准。
常见问题
团队同时有合规留存要求和快速迭代的构建产物，规则应该怎么拆？
按制品类型拆开处理，不必用一套规则覆盖全部对象。有法定或合同留存要求的交付物，按时间设定保留期限，并把正式发布纳入基线留存，确保期限之外的重要版本仍可取回；依赖包、内部组件这类迭代频繁的对象，按版本数量控制份数，给仓库体积设上限；临时构建产物和测试中间产物可以设更短的时间期限。拆分后每类规则的目标单一，调整时也不会互相牵制。
按版本数量保留时，低频制品长期占用名额怎么处理？
版本份数规则对高频和低频制品一视同仁，低频制品保留最近几个版本可能跨越很长时间，实际回溯价值有限。可以在数量规则之外补充一条时间上限：超过一定期限的版本即使仍在份数范围内也进入清理。反过来，对高频制品要确认份数覆盖的回溯窗口是否够用，一天多次构建的制品保留五份可能只覆盖半天，需要按实际回溯需求调大份数或改用时间规则。
发布基线标记漏做导致制品被清理，有什么预防办法？
基线留存的前提是发布时正确标记。可以从流程和工具两侧降低漏标风险：把基线标记设为发布流程的必经节点，未标记不允许发布完成；清理规则执行前先预览受影响的制品范围，人工确认没有本应属于基线的制品；定期抽查已发布版本与基线记录的对应关系。已经发生的漏标，只能依靠备份或更长的保留期限兜底，因此对重要发布建议保留一份独立的制品清单。
基线数量增长后，存储压力怎么控制？
每条基线都完整保留制品，基线数量随时间累积，存储压力会持续上升。常见做法是分层保留：最近若干条基线保留完整制品集合，更早的基线只保留制品清单和关键制品，其余按时间或数量规则清理。分层的前提是清单本身足以支撑追溯，需要确认清单记录了制品标识、版本和校验信息。分层规则要写入保留策略并定期复核，避免早期基线在无人察觉时被整体清空。
在制品管理工具中配置保留规则前，需要核对哪些能力？
建议核对三点：保留规则能否按仓库或制品类型分别配置，以支撑交付物、依赖包、临时产物采用不同策略；基线制品能否被排除在时间或数量清理规则之外，保证底线不被误清；清理执行前能否预览受影响的制品范围，便于人工确认。这三点决定工具能否支撑“基线为底线叠加清理规则”的组合方案，具体支持情况以产品实际资料为准。
