学习用途:用于制品库规划、历史数据治理
目录
一、制品生命周期管理解决什么问题
二、制品生命周期是什么
三、中间制品和正式制品应分类管理
四、典型问题一:CI 中间制品持续增长
处理建议
五、典型问题二:正式版本不能只按时间清理
六、典型问题三:下载记录缺少次数和用途信息
七、典型问题四:下载记录不能代表实际生产使用
八、典型问题五:正式制品不适合直接自动删除
职责划分
九、常见治理问题汇总
十、通用生命周期治理方案
10.1 生命周期治理需要哪些数据
10.2 生命周期治理的判断流程
10.3 生命周期治理的核心判断
十一、总结
一、制品生命周期管理解决什么问题
制品库初期主要解决软件包统一存储问题。随着 CI 持续运行,制品数量和存储占用不断增加,管理重点会逐步转向:
哪些制品需要保留,哪些可以退出,以及依据什么进行判断。
例如,一个项目每天构建 20 次,每次产生约 300 MB 制品,理论上一年产生:
20 × 300 MB × 365 ≈ 2.19 TB /年
实际空间占用还会受到压缩、去重和清理策略影响,但持续构建带来的历史数据增长是长期存在的问题。
制品类型 + 当前状态 + 时间 + 使用情况 + 发布/交付关系
二、制品生命周期是什么
一个制品从产生到退出,大体经历以下阶段:
阶段 | 管理重点 |
产生 | Commit、Build、Version、来源 |
存储 | 分类、容量、Checksum |
使用 | 下载人员、次数、用途 |
验证 | Test、UAT、RC 状态 |
发布 | 正式版本、发布时间、目标环境 |
保留 | 实际使用情况、回退要求 |
退出 | 是否仍有生产或交付关系 |
清理 | 责任确认、执行和留痕 |
三、中间制品和正式制品应分类管理
不同制品的用途、价值和保留要求不同,应采用不同的生命周期策略。
类型 | 典型示例 | 特点 | 管理方式 |
中间制品 | Snapshot、CI Build、测试版本、UAT 候选版本、临时镜像 | 数量多、产生频率高、使用周期短 | 控制数量、保留周期和清理规则 |
正式制品 | Release、生产版本、正式交付版本、故障回退版本 | 数量较少、影响范围大、保留要求高 | 保证可追溯、可获取,并受控退出 |
四、典型问题一:CI 中间制品持续增长
持续集成可能不断产生中间制品:
Build #101 → #102 → #103 → #104 → ……→ #500
其中真正进入正式发布的可能只有 #126、#235、#410。若所有 Build 长期保留,会积累大量使用价值较低的过程制品。
处理建议
规则维度 | 示例 |
时间 | 保留最近 30 天 |
数量 | 保留最近 20 次 Build |
使用情况 | 长期未使用的制品进入待清理范围 |
特殊保护 | RC、故障定位版本、人工指定版本单独保留 |
规则筛选 → 识别保护对象 → 形成候选范围 → 执行处理
中间制品适合更多采用规则化和自动化治理。
五、典型问题二:正式版本不能只按时间清理
正式制品即使创建时间较早,也可能仍有保留价值。以已存在两年的 V1.2.0 为例:
实际情况 | 处理判断 |
正在生产环境运行 | 保留 |
客户仍在使用 | 保留 |
当前故障回退版本 | 保留 |
长期维护项目正式版本 | 保留 |
最近仍有发布、下载或交付记录 | 进一步确认 |
已退出使用且责任方确认不再需要 | 可进入清理流程 |
正式制品不能只看创建时间,应综合创建时间、最近使用时间、当前状态、发布记录、交付记录和项目状态。
中间制品更多关注 Age + Count;正式制品更需要关注 Usage + Release + Business。
六、典型问题三:下载记录缺少次数和用途信息
仅记录“是否下载过”不足以支撑生命周期判断。更有价值的使用记录应包含:
信息 | 作用 |
最近下载时间 | 判断近期是否仍有使用行为 |
下载次数 | 判断使用频率 |
下载用途 | 判断测试、部署、交付、排障等实际用途 |
下载人员 | 支持后续追溯和责任确认 |
制品 | 最近下载 | 次数 | 最近用途 | 当前状态 | 初步判断 |
制品 A | 2026-08 | 18 | 生产部署 | 正式版本 | 仍有明确使用价值 |
制品 B | 2026-07 | 3 | 问题排查 | 历史正式版本 | 暂不适合按时间清理 |
制品 C | 2024-05 | 1 | 测试验证 | 临时测试版本 | 可进入清理候选 |
下载用途可统一为:测试验证、UAT、生产部署、客户交付、问题排查、其他。
生命周期判断应结合:下载时间 + 下载次数 + 下载用途。
七、典型问题四:下载记录不能代表实际生产使用
下载行为和实际部署属于不同类型的信息。某个制品最近被下载,不代表正在生产运行;生产环境中的稳定版本也可能长期没有重新下载。
记录类型 | 内容 | 作用 |
下载记录 | 下载人员、时间、次数、用途 | 判断访问和使用情况 |
发布记录 | Version、发布时间、目标环境 | 判断实际部署情况 |
交付记录 | Version、交付对象、时间、批次 | 判断业务交付关系 |
下载记录与部署/发布记录应通过制品版本、Artifact ID 或 Checksum 建立关联;条件允许时可在同一系统统一记录。判断正式制品是否仍在使用时,应结合发布和交付关系,而不能仅根据下载行为推断。
八、典型问题五:正式制品不适合直接自动删除
系统通常能够识别创建时间、文件大小、下载次数、最近使用时间和当前状态等技术数据,但这些数据不能完全说明正式制品是否仍具有业务价值。
数据统计 → 规则筛选 → 待清理候选 → 责任方确认 → 执行清理
职责划分
角色 | 职责 |
平台侧 | 数据统计、规则筛选、候选清单、清理能力和操作留痕 |
项目/责任方 | 确认实际使用状态、判断正式版本是否继续保留、确认清理范围 |
技术上长期未使用 ≠ 业务上已经没有价值。
九、常见治理问题汇总
问题 | 风险 | 建议 |
所有制品使用相同保留周期 | 正式版本可能被误清理,中间版本长期堆积 | 按类型和状态制定策略 |
只按创建时间判断 | 无法识别仍在使用的历史版本 | 结合使用、发布和交付 |
把无人下载当作无人使用 | 可能误判稳定运行的生产版本 | 下载记录与部署记录关联管理,结合制品版本判断实际使用状态 |
正式版本自动删除 | 技术数据无法完全判断业务价值 | 先形成候选,由责任方确认 |
只清理磁盘不治理生命周期 | 空间释放后仍会再次无序增长 | 建立分类、状态和保留规则 |
十、通用生命周期治理方案
针对前述典型问题,通用治理可从数据基础、判断流程、责任边界和治理能力四个方面建立。
10.1 生命周期治理需要哪些数据
数据维度 | 典型字段 | 用途 |
身份 | 项目、制品名称、Version、类型、Checksum | 确认制品身份 |
容量 | Size | 分析存储占用 |
时间 | 创建时间、上传时间、最近下载时间 | 判断生命周期 |
使用 | 下载次数、下载人员、下载用途 | 判断实际使用情况 |
状态 | 中间、测试、RC、正式 | 区分管理策略 |
发布 | 发布环境、发布时间、部署版本 | 判断实际部署情况 |
交付 | 交付对象、交付时间、交付批次 | 判断业务使用关系 |
这些数据最终用于回答:这个制品是否仍具有保留价值。
10.2 生命周期治理的判断流程
生命周期治理可以简化为三个步骤:分类、判断、处理。
10.3 生命周期治理的核心判断
- 中间制品和正式制品分类管理。
- 正式制品不能只按创建时间判断。
- 下载时间、次数和用途反映使用情况,并应与部署/发布记录关联判断。
- 平台负责提供数据和候选范围,正式制品退出需要责任方确认。
十一、总结
制品生命周期管理的核心问题不是“如何删除历史制品”,而是如何判断一个制品是否仍具有保留价值。
制品类型 + 当前状态 + 时间 + 使用情况 + 发布/交付关系
中间制品适合通过时间、数量和使用规则进行治理;正式制品需要结合生产部署、项目状态、交付关系和回退要求进行判断。
让制品从产生、使用、发布到退出均有明确状态和判断依据,使存储增长可观察、历史版本可追溯、正式制品可受控管理。