构建产物存储与分发需统一管理、按需供给、安全可追溯：使用专业制品仓库替代临时目录，入库带完整元数据，按类型与环境分离存储，打通流水线与部署的制品标识链，设置生命周期策略与细粒度权限，并启用签名验证。
构建产物的存储与分发不是“存完就走”的简单动作，而是影响部署可靠性、环境一致性与团队协作效率的关键环节。核心在于：统一管理、按需供给、安全可追溯。
用制品仓库替代临时目录
很多团队把构建产物（如 JAR、Docker 镜像、打包后的 dist 文件）直接扔进 Git 仓库、本地 NFS 或临时服务器目录，结果是版本混乱、无法回滚、多人覆盖风险高。
- 必须使用专业制品仓库，如 Nexus、Artifactory、JFrog、Harbor（镜像专用）或云厂商托管服务（如 AWS ECR、阿里云 ACR、GitHub Packages）
- 制品入库要带明确元数据：构建流水线 ID、Git 提交哈希、分支名、环境标识（如 prod-v1.2.0-abc123），避免仅用 latest 标签
- 禁止在 CI 脚本中用 scp/rsync 直传文件到目标服务器——这绕过审计、丢失溯源、难做权限控制
按环境与用途分离制品类型
不是所有产物都该进同一个仓库，也不是所有环境都该用同一套分发逻辑。
- 编译产物（.jar/.war/.dll）进 Maven/NuGet 仓库，供后续部署阶段拉取
- Docker 镜像进容器注册表（如 Harbor），由 Kubernetes 或 Docker Swarm 按 imagePullPolicy 拉取
- 前端静态资源（HTML/JS/CSS）建议上传至对象存储（如 OSS/S3），配合 CDN 加速，而非打包进后端镜像
- 测试用的快照版（snapshot）和发布用的正式版（release）应物理隔离，避免测试污染生产
打通流水线与部署系统的制品引用链
分发失效，常因“构建时生成了 A 版本，部署时却用了 B 版本”——根源是制品标识未全程绑定。
- 构建阶段生成唯一制品 ID（如 $CI_COMMIT_SHA-$CI_PIPELINE_ID），写入环境变量并持久化到制品元数据中
- 部署阶段严格读取该 ID，而不是靠分支名或 latest 标签动态解析——Git 分支可能被 force push，latest 可能被覆盖
- 在 Kubernetes Deployment 中用 image 字段硬编码具体镜像 digest（sha256:...），而非 tag；或通过 Helm Chart 的 values.yaml 注入已知可靠版本
- 推荐在流水线末尾生成一份 manifest.json，记录本次构建所有产物路径、校验和、签名信息，供下游系统校验完整性
设置合理的生命周期与权限策略
没人清理的仓库会变成“数字垃圾场”，既占空间又埋隐患。
- 为不同仓库配置自动清理规则：比如只保留最近 30 天的 snapshot，保留全部 release 版本，但超过 2 年无下载记录的自动归档
- 按角色分配权限：开发人员可读写 dev 分支制品，QA 只读 test 环境制品，运维只读 prod 制品且不可删除
- 对关键 release 制品启用 GPG 签名或 cosign 签名，在部署前验证签名有效性，防止中间篡改
