2. 制品管理基础：什么是制品（Artifact）、制品仓库（如 Nexus, Artifactory）的核心概念
2.1 制品（Artifact）的定义与生命周期
在 DevOps 与 CI/CD 流水线中，制品（Artifact） 是指软件开发过程中产生的、可交付或可部署的产物。它通常是构建阶段输出的二进制文件、压缩包或容器镜像，是“源代码”到“运行环境”之间的关键中间态。
核心定义： 制品是经过编译、打包、测试验证后，具备版本标识且可直接部署到目标环境的不可变产物。
典型的制品类型包括：
- 编译产物： JAR、WAR、EAR（Java 生态）；DLL、EXE（.NET 生态）；.whl（Python 包）；.gem（Ruby 包）。
- 镜像与容器： Docker 镜像、OCI 镜像、Helm Chart 包。
- 安装包： .deb、.rpm、.msi、.pkg。
- 配置文件与脚本： 经过参数化处理的 YAML、JSON、Shell 脚本归档。
制品的生命周期通常包含以下阶段：
| 阶段 | 说明 | 关键动作 |
|---|---|---|
| 构建 | 从源代码编译、打包生成原始制品 | Maven package、npm run build |
| 存储 | 上传至制品仓库，保留版本与元数据 | mvn deploy、docker push |
| 验证 | 安全扫描、签名校验、质量门禁 | Trivy 扫描、GPG 签名 |
| 部署 | 从仓库拉取指定版本到目标环境 | kubectl apply、ansible-playbook |
| 归档/清理 | 按策略保留或删除旧版本制品 | 保留最近 N 个版本、按日期清理 |
版本冻结的关键前提： 只有将制品视为“不可变对象”，并为其分配唯一版本号（如
v1.2.3+build.20250401），才能实现精确的回滚与冻结。任何对已发布制品的修改都应生成新版本，而非覆盖旧版本。
2.2 制品仓库（Artifact Repository）的核心概念
制品仓库是集中存储、管理、分发制品的平台。它解决了“制品散落在各构建节点”、“版本混乱”、“依赖不可追溯”等痛点。常见的商业与开源方案包括 Sonatype Nexus、JFrog Artifactory、Harbor（容器镜像）、AWS CodeArtifact 等。
制品仓库的核心能力可归纳为以下四个维度：
- 代理与缓存（Proxy & Cache）： 代理外部公共仓库（如 Maven Central、Docker Hub），将下载过的依赖缓存到本地，加速构建并减少外网依赖。
- 托管与版本管理（Hosted & Versioning）： 存储组织内部构建的私有制品，支持语义化版本、时间戳版本、快照版本，并提供保留策略。
- 分组与虚拟仓库（Group & Virtual Repository）： 将多个代理仓库和托管仓库聚合成一个统一入口，简化客户端配置。例如：将所有 Maven 仓库聚合为一个
maven-all地址。 - 安全与审计（Security & Audit）： 支持 RBAC 权限控制、制品签名校验、恶意依赖扫描、操作审计日志。
2.3 制品仓库架构示意图
下图展示了一个典型的制品仓库内部结构，以及它与 CI/CD 流水线、外部公共仓库的关系：
2.4 Nexus 与 Artifactory 核心对比
下表从关键维度对比两款主流制品仓库，帮助团队根据自身场景选型：
| 对比维度 | Sonatype Nexus | JFrog Artifactory |
|---|---|---|
| 许可证 | OSS 版免费（功能受限），Pro 版付费 | OSS 版免费（功能较少），Pro/Enterprise 付费 |
| 包类型支持 | Maven、npm、Docker、PyPI、NuGet 等 30+ | Maven、npm、Docker、PyPI、Go、Helm 等 40+ |
| 高可用架构 | Pro 版支持集群部署 | Enterprise 版支持多活集群 |
| 制品扫描 | 需集成第三方工具（如 SonarQube） | 内置 Xray 深度扫描（依赖分析+漏洞） |
| 虚拟仓库 | 支持（Group Repository） | 支持（Virtual Repository） |
| 清理策略 | 基于时间/版本数的自动清理 | 基于时间/版本数/使用频率的智能清理 |
| REST API | 完整，但部分操作需 Pro | 完整，支持脚本化批量操作 |
选型建议： 如果团队以 Java/Maven 生态为主且预算有限，Nexus OSS 是成熟选择；如果涉及多语言、容器镜像、Helm Chart 且需要深度安全扫描，Artifactory Pro/Enterprise 的综合能力更强。无论选择哪款，版本冻结策略 都需要依赖仓库的“不可变制品”特性——即制品一旦发布，其内容与版本号均不可修改。
2.5 制品仓库在版本冻结中的关键角色
在后续章节的“版本冻结策略”中，制品仓库将承担以下核心职责：
- 版本锁定： 通过仓库的
release类型仓库，确保冻结版本不会被覆盖或删除。 - 快照隔离： 将开发中的 SNAPSHOT 版本与正式 Release 版本物理隔离，防止误用。
- 回滚溯源： 仓库保留每个版本的构建时间、构建编号、Git Commit SHA、构建参数等元数据，为回滚提供精确的“版本快照”。
- 清理策略配合： 冻结的版本应被排除在自动清理规则之外，避免因清理导致回滚目标丢失。
实践要点： 在制品仓库中为每个项目创建独立的
releases 和 snapshots 仓库，并设置 Deployment Policy 为 “Disable Redeploy”（禁止重新部署），这是实现版本冻结的第一道防线。