企业官网建设流程全解析

一、什么是软件制品，管理范围是什么

在广义软件工程语境中，Artifact（制品/工件）可以指研发过程中形成的各种工作产品；但在 DevOps、制品库和软件供应链管理场景中，通常更关注由源代码经过编译、构建、打包后形成，并用于后续测试、发布、部署或交付的软件产物。

本文采用这一较窄且更适合工程实践的定义：软件制品，是源代码经过构建过程形成、可以被后续环节直接使用的软件交付产物。

本文重点讨论内部研发构建产生的制品；第三方软件包、基础镜像和公共依赖等外部制品，在实际制品管理中也可以作为管理对象

• JAR、WAR 等 Java 二进制包；
• ZIP、TAR 等通用交付包；
• Docker / OCI 镜像；
• 安装包、可执行文件；
• Maven、npm、PyPI 等软件包；
• Helm Chart、SDK、内部公共组件及其他可部署或可交付的二进制产物。

制品管理真正管理的也不只是“文件本体”。一个可管理的软件制品，通常还需要关联能够证明它是谁、从哪里来、处于什么状态以及如何被使用的元数据。

二、为什么要做制品管理

与其先从“制品库应该有哪些功能”出发，更容易理解的方式，是先看不做制品管理时会出现哪些典型反模式，再看制品管理能够解决什么问题。

2.1 不做制品管理的问题（反模式）

反模式 1：二进制文件混入源代码仓库

将 JAR、ZIP、安装包、镜像导出文件等大体积二进制长期提交到普通 Git 仓库，会让代码仓库承担它本来不擅长的二进制分发职责。随着版本增加，仓库历史持续膨胀，克隆、拉取和维护成本随之增加，源代码版本和软件制品版本也容易混在一起。

反模式 2：通过私有渠道传递软件包

通过即时通讯、网盘、个人目录、临时共享盘等方式传递软件包，短期看很方便，但很难保证所有人拿到的是同一版本，也难以完整记录下载、替换、发布和交付过程。对于正式软件版本，这种方还会增加未经授权访问、篡改和来源不清等风险。

反模式 3：软件包数量和版本快速膨胀

持续集成会不断产生 Snapshot、测试包、候选版本、临时镜像等中间产物。如果所有产物都永久保留，制品数量和存储空间会持续增长。问题并不只是“磁盘不够”，更重要的是无法区分哪些是短期过程数据、哪些是需要长期保留的正式版本。

反模式 4：包版本不一致导致生产事故

当测试、UAT 和生产环境不是使用同一份已验证制品，而是在不同环境重新构建、人工复制或选择“最新包”时，就可能出现环境之间的软件内容不一致。版本号相同也不能证明二进制完全相同，因此需要通过不可变制品和 Checksum 等方式识别实际发布内容。

2.2 做制品管理的七大理由与好处

1. 实现可追溯性

每个制品都应有明确身份，并能够关联到产生它的源码版本、构建过程和构建系统。出现问题时可以从生产版本反向找到 Artifact → Build → Commit。

2. 实现可重现性

制品仓库保存已生成的版本；同时，源码、构建说明、依赖和构建环境信息被保留下来后，即使制品意外丢失，也有条件重新构建并验证结果。

3. 保障安全与合规

正式软件包不应散落在个人目录或不受控渠道中。集中制品库可以统一访问控制、完整性校验、审计留痕，并与漏洞扫描、签名等安全能力结合。

4. 规范跨角色协作

研发、测试、运维、交付人员围绕同一个受信软件源获取版本，可以减少“你手里的包”和“我手里的包”不一致的问题，并明确哪个版本属于测试、候选或正式版本。

5. 统一管理外部依赖

Maven、npm、PyPI 等第三方依赖可以通过组织内部代理仓库统一获取和缓存，降低对公网可用性、下载位置和个人本地缓存的依赖，并为后续审计和安全控制提供统一入口。

6. 支撑自动化流水线——一次构建，多次使用

构建完成后将制品固定下来，测试、UAT、生产等环境使用同一份已验证二进制，而不是每个环境重新构建。这样可以减少环境差异造成的发布偏差。

7. 解决存储空间膨胀

制品库可以把临时构建产物和正式版本分开管理，并基于时间、版本数量、使用情况和状态建立保留策略，使存储增长从“无序累积”变成“可观察、可治理”。

三、制品管理位于软件生命周期什么位置

理解制品管理，不能只看制品库本身，而要把它放到完整的软件研发与交付链路中。从一个简化的软件生命周期来看，可以表示为：

图 1 制品管理在软件研发过程中的位置

从这条链路看，制品管理位于“软件构建完成”与“测试、发布和交付”之间。它既不是源代码管理，也不是最终部署系统，而是承接构建结果、形成确定软件版本并向下游交付的中间枢纽。

3.1 上游：承接代码与构建结果

开发人员持续修改的是源代码，而测试和生产环境真正使用的是构建后的软件包或镜像。制品管理通过关联 Git Repository、Branch/Tag、Commit ID、CI Job 和 Build Number，把构建产物与上游代码来源连接起来。

3.2 中间：给构建结果一个明确的软件身份

Jenkins Workspace 中的 target/app.jar 只是一个文件。进入制品管理后，需要被赋予项目、制品名称、版本、Checksum、Build 和状态等信息，从而从“一次性的构建输出”变成“组织可以识别的软件版本”。

3.3 下游：为测试、发布和交付提供确定版本

测试、UAT 和生产发布针对的应该是一个确定的制品版本，而不是“最新代码”或“最新构建的包”。当同一份制品在不同阶段被验证和晋级后，生产环境才能明确知道最终部署的究竟是哪一个版本。

因此，制品管理可以理解为把研发阶段不断变化的代码状态，转换为下游可以稳定测试、发布、交付和回退的确定软件版本。

四、从三个理论视角理解制品管理

4.1 配置管理视角：识别和控制软件版本对象

从软件配置管理角度看，制品属于需要被识别、版本化和受控的配置对象之一。管理重点不是“文件有没有”，而是明确对象身份、版本状态、变更关系和可追溯性，使后续发布和问题定位有确定依据。

4.2 DevOps 视角：连接 CI 与 CD

CI 负责把源代码转换为可用的软件产物；制品管理负责保存、识别和提供这些产物；CD 再选择经过验证的制品发布到目标环境。三者形成的关系可以概括为：CI 产生制品，制品库保存可信版本，CD 消费并发布指定版本。

4.3 软件供应链视角：建立来源和完整性证据

现代软件供应链不仅关注“有没有这个包”，还关注“它从哪里来、由什么过程产生、是否被替换”。SLSA Provenance 强调记录软件制品产生时的来源、构建过程和输出摘要；NIST SSDF 则强调对可执行代码实施受控访问与完整性保护 。因此，Commit、Build、Checksum、签名、依赖和安全结果都可以逐步成为制品可信度的一部分。

五、结论

软件制品管理最初往往从“构建包放在哪里”开始，但真正进入工程化以后，需要进一步解决版本身份、来源追溯、环境一致性、安全控制、跨角色协作和生命周期治理等问题。

从整个研发流程看，制品管理位于代码构建和软件交付之间：上接源代码和 CI 构建，下接测试、发布、部署和交付。它的核心作用，是把一次性的构建结果转化为具有明确身份、可信来源、可重复获取和受控生命周期的软件版本载体。