Nexus制品晋级审批流设计 - 第1节
1.1 什么是制品晋级
制品晋级（Artifact Promotion）是指将软件制品在生命周期中从一个阶段或仓库提升到下一个阶段的过程。在持续交付流水线中，制品从开发、测试、预发布到生产环境，每个阶段对应不同的质量门禁和审批要求。
制品晋级不是简单的文件复制，而是伴随元数据更新、签名验证、安全扫描、合规审计的受控状态变更。每次晋级都意味着制品通过了当前阶段的所有质量关卡，可以进入更接近生产的环境。
核心概念：制品晋级 = 制品状态变更 + 元数据升级 + 环境迁移。晋级后的制品保留完整的溯源链，确保“从源码到生产”全程可追溯。
制品晋级的典型阶段
| 阶段 | 仓库名称 | 制品状态 | 质量要求 |
|---|---|---|---|
| 开发 | snapshot | 快照 | 编译通过 |
| 测试 | test | 候选 | 单元测试通过 |
| 预发布 | staging | 预发布 | 集成测试、安全扫描通过 |
| 生产 | release | 正式发布 | 全量验收、合规审批通过 |
1.2 为什么需要晋级审批流
没有审批流的制品晋级，本质上等同于“无管控发布”。在大型企业或合规敏感行业，直接向生产仓库推送制品会带来以下风险：
- 质量失控：未经验证的制品进入生产环境，可能导致线上故障或数据泄露。
- 合规缺失：金融、医疗、政务等行业要求制品发布必须经过指定角色审批并留痕。
- 溯源断裂：缺少晋级记录，无法追溯哪个制品、由谁、在什么时间、基于什么审批进入了生产。
- 权限混乱：开发人员直接操作生产仓库，违背最小权限原则和职责分离要求。
常见误区：部分团队认为“自动化流水线不需要人工审批”。实际上，自动化负责执行，审批流负责决策。安全扫描失败时自动阻断是自动化，但“是否允许带已知低危漏洞上线”需要人工审批。
晋级审批流的核心价值
| 价值维度 | 说明 | 典型场景 |
|---|---|---|
| 质量保障 | 每个晋级节点强制执行质量门禁 | 单元测试覆盖率 > 80% 才允许晋级 |
| 合规审计 | 完整记录谁、何时、为何批准晋级 | SOX、PCI-DSS、GDPR 合规要求 |
| 风险控制 | 人工审批介入高风险决策 | 生产发布需要架构师或安全官签字 |
| 职责分离 | 开发、测试、运维角色各司其职 | 开发者不能直接批准自己的制品上线 |
| 可追溯性 | 晋级链完整，支持快速回滚定位 | 生产事故时回溯制品变更历史 |
1.3 Nexus 在制品管理中的角色
Nexus Repository 是企业级制品管理的核心基础设施，它不仅是制品的存储仓库，更是制品晋级流程的执行平台。Nexus 在制品管理中承担以下关键角色：
- 统一存储：集中管理 Maven、npm、Docker、PyPI、NuGet 等所有主流制品类型。
- 仓库分层：通过 hosted、proxy、group 三种仓库类型构建制品分级体系。
- 权限控制：基于角色的细粒度权限，控制谁可以读取、部署、删除制品。
- 晋级引擎：通过 Content Selector、Staging、Promotion API 实现自动化晋级。
- 审计溯源：完整记录制品的上传、下载、晋级、删除等所有操作。
最佳实践：将 Nexus 仓库按环境分层（dev/test/staging/prod），每个仓库对应一个晋级阶段。通过 Nexus 的 Staging 功能，在正式发布前创建暂存仓库，审批通过后再合并到目标仓库。
Nexus 仓库分层与晋级关系
Nexus 通过三种仓库类型构建制品晋级的基础设施：
| 仓库类型 | 用途 | 晋级角色 |
|---|---|---|
| Hosted（托管） | 存储组织内部构建的制品 | 作为各阶段的目标仓库 |
| Proxy（代理） | 缓存远程公共仓库的制品 | 提供外部依赖，不参与晋级 |
| Group（组） | 聚合多个仓库对外提供统一视图 | 消费端统一入口，屏蔽底层仓库变化 |
晋级实践：在 Nexus 中为每个环境创建独立的 Hosted 仓库（如 dev-repo、test-repo、staging-repo、prod-repo）。制品通过 Promotion API 或 Staging 流程在仓库间移动，每次移动都触发审批流。Group 仓库指向当前环境对应的 Hosted 仓库，实现环境隔离。