应用开发中的 Artifact：定义、类型与管理方法

什么是 Artifact

Artifact（构建制品）——是源代码编译的结果，准备部署或作为依赖使用。构建过程将源文件（Java、Kotlin、Swift、C++ 等）转换为可在目标设备或服务器上运行的二进制包。

制品的概念超越了可执行文件。例如，JAR 库——是在其他项目中用作依赖的制品。Docker 镜像——包含应用程序及其环境的制品。即使是测试覆盖率报告在 CI/CD 上下文中也可以被视为制品。

现代大型公司的开发工作涉及管理数十万个制品。Google DORA 将制品管理的成熟度与 DevOps 的整体效率联系起来——使用制品注册表的团队发布版本更快，部署时遇到的问题也更少。

制品的生命周期

每个制品经历几个阶段：创建（构建、编译）、验证（测试、安全检查）、存储（制品注册表）、分发（发布以供下载）和归档或删除（当版本过时时）。

移动开发中的制品类型

不同的平台和技术生成不同的制品格式。了解格式对于正确配置 CI/CD 管道和选择存储系统是必要的。

Android 制品

APK（Android Package Kit）——传统的安装包格式。AAB（Android App Bundle）——在 Google Play 上发布的现代格式，仅包含特定设备所需的资源。AAB 可减少安装的应用程序的大小，与通用 APK 相比平均减少 15-20%。

iOS 制品

IPA（iOS App Store Package）——包含 iOS 设备代码和资源的归档文件。XCArchive——由 Xcode 创建的中间制品，从中导出最终的 IPA。dSYM——用于符号化崩溃日志所需的调试文件。

服务器和库项目的制品

JAR（Java ARchive）——用于 Java/Kotlin 库。AAR（Android ARchive）——用于带资源的 Android 库。Docker 镜像——用于微服务的容器制品。每种类型都有其自己的注册表和版本管理规则。

CI/CD 管道中的制品

制品——管道阶段之间的连接环节。每个阶段消耗前一阶段的制品并产生新的制品。理解这种流程对于配置高效的 CI/CD 至关重要。

管道中的制品流

典型流程包括：提交 → 构建服务器编译代码并创建未优化的制品 → 测试制品用于运行测试 → 成功后创建发布制品 → 签名后在制品注册表中发布 → 从注册表中提取制品以部署到预发布和生产环境。每个阶段之间的转换都伴随着完整性和合规性验证。

中间和最终制品

管道可以在不同阶段创建多个制品。调试制品包含调试信息，未优化的——快速构建用于测试，发布制品——经过优化和混淆处理的最终版本。CI 系统必须能够区分它们并为每种类型应用适当的存储策略。

name: Artifact Flow
on: [push]

jobs:
  build-debug:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew assembleDebug
      - uses: actions/upload-artifact@v4
        with:
          name: debug-apk
          path: app/build/outputs/apk/debug/app-debug.apk
          retention-days: 7

  test:
    needs: build-debug
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: debug-apk
      - run: ./gradlew testDebugUnitTest

  build-release:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/app-release.apk
          retention-days: 90

缓存与制品

区分依赖缓存和构建制品很重要。缓存（Gradle 缓存、CocoaPods 缓存）加速重复构建，但不用于部署。制品——准备分发的最终产品。对于缓存设置几天的 TTL，对于制品设置数周或数月。

制品仓库

制品不应存储在构建服务器上——为此有专门的系统。仓库管理器提供集中存储、索引、访问控制以及与 CI/CD 工具的集成。

流行的制品注册表

JFrog Artifactory——支持 Maven、Gradle、Docker、NuGet、npm、APT、YUM 的通用管理器。Sonatype Nexus——支持主要格式的开源替代方案。GitHub Packages——GitHub 内置的注册表，适合已在使用 GitHub 的团队。GitLab Container Registry——用于 Docker 镜像。

选择注册表的标准

主要因素：支持的格式、许可模式（开源/企业版）、与现有 CI/CD 的集成、跨区域复制能力、旧版本自动清理策略的存在以及合规报告。

// Jenkins 管道 — 在 Artifactory 中发布 APK
def server = Artifactory.newServer(
    url: 'https://artifactory.company.com',
    credentialsId: 'artifactory-api-key'
)

def uploadSpec = """
{
  "files": [
    {
      "pattern": "app/build/outputs/apk/release/*.apk",
      "target": "mobile-apps/android/release/""
    }
  ]
}
"""
server.upload(uploadSpec)

版本控制与命名

正确的制品版本控制策略对于构建的可重现性和变更追踪至关重要。没有版本控制，就无法确定生产环境中导致问题的代码版本。

语义化版本控制（SemVer）

MAJOR.MINOR.PATCH 标准：MAJOR 在不兼容的 API 更改时改变，MINOR——在添加向后兼容的功能时改变，PATCH——在向后兼容的修复时改变。对于 CI/CD，版本会添加构建元数据：2.4.1+build.20260703.1。这样可以精确确定哪个提交生成了特定的制品以及它是什么时候创建的。

可追溯性——与 Git 的关联

每个制品应包含关于其来源的元数据：提交 SHA、CI 构建编号、分支名称、构建日期。这些信息记录在制品的清单中，并允许随时重建其创建的上下文。没有可追溯性，与制品的工作就变成了版本猜测，这对于有审计要求的生产系统是不可接受的。

制品命名

命名约定：{项目}-{模块}-{版本}.{扩展名}。例如：`messaging-sdk-2.4.1.aar` 或 `app-release-2.4.1.apk`。构建服务器可以根据 Git 标签或 CI 构建编号自动生成版本。

• 使用 Git 标签作为版本来源——将制品与特定的代码状态关联起来
• 将提交 SHA 添加到元数据中，以便在调试阶段进行精确定位
• 配置保留策略——保留最后 N 个版本，其余的归档

快照与发布

在 Maven/Gradle 制品注册表中，区分发布版本（固定的、不可变的）和快照版本（当前开发中的，可被覆盖）。在 CI/CD 管道中，快照制品便于开发，但在生产环境中应仅使用发布版本。

制品安全

制品——软件供应链的关键元素。制品被篡改可能导致恶意代码进入生产环境。制品安全包括多个保护级别。

制品签名

APK 文件使用 jarsigner 或 apksigner 签名；IPA——使用 Apple 证书；Docker 镜像——使用 Docker 的 Content Trust（Notary）。签名保证完整性并确认制品的作者。CI/CD 管道应包括所有第三方依赖的签名验证。

漏洞扫描

在发布之前，制品由自动扫描器检查：Snyk、Trivy、Sonatype Nexus IQ、GitHub Dependabot。它们分析包含的依赖项、所使用的库的版本以及已知的 CVE 漏洞。如果发现严重漏洞，发布将立即被阻止，直到开发人员修复它。

供应链级别

SLSA（软件制品的供应链级别）——定义从 SLSA 1（基本）到 SLSA 4（最高）信任级别的安全框架。构建服务器必须生成来源证明（provenance attestation）——一种加密签名的凭证，说明制品是如何以及从什么代码构建的。