Android / iOS / HarmonyOS 都要发？这是我当前最顺的一套内测流程

原创已于 2025-11-17 12:09:59 修改 · 924 阅读

CC 4.0 BY-SA版权

文章标签：

于 2025-11-14 10:54:23 首次发布

在一个多端（Android / iOS / HarmonyOS）项目中，把内测包发给测试人员是一项长期存在但容易被低估的问题。我们团队之前用自己搭服务器、自建下载页、文件网盘，流程不统一、版本混乱、沟通效率低。后来我们把内测分发迁到 蒲公英（pgyer.com），结合 CI/CD 实现自动化，才真正把发包环节变成可控、标准、稳定的一部分。

下面是我们的技术实践、思考与脚本示例。

核心诉求与技术选型分析

我们为什么要换一个内测分发方案

高频构建：我们每天构建多个版本，发包频率高。
多平台支持：项目同时维护 Android (.apk)、iOS (.ipa)、HarmonyOS (.hap) 包。
测试组管理复杂：不同测试组（功能测试、兼容测试、特殊机型）对版本的需求不同。
自动化需求强：希望 CI 完成构建后自动发包，不要人为干预。
稳定性与安全性：分发平台必须可靠，包不能丢、链接不能乱。

蒲公英满足了以上技术诉求

支持 API 上传：使用 API 2.0 上传应用包，鉴权机制明确。pgyer.com+1
多种上传方式：网页、客户端、小程序都支持。pgyer.com
HarmonyOS 包支持：已支持 .hap 文件，并支持上传对应的 .p12 证书用于签名。upload.pgyer.com
安装页面统一管理：上传后可以设置版本信息、更新说明、渠道控制。
自动化友好：结合 CI/CD 脚本，构建完成后上传迅速、可靠。

HarmonyOS (.hap) 分发实践细节

.hap 文件必须是已签名版本，签名步骤需使用华为 DevEco-Studio 等工具完成。upload.pgyer.com
必须上传与 .hap 签名时所用证书一致的 .p12 文件，并提供密码，用于蒲公英对 manifest.json5 文件签名。upload.pgyer.com
上传 .p12 后，蒲公英会自动生成安装元数据，支持生成安装页面和下载链接。upload.pgyer.com
下载方式：测试人员可通过蒲公英生成的链接或二维码，在 纯血 HarmonyOS NEXT 设备 的浏览器中下载安装。upload.pgyer.com
注意签名一致性：.hap 本体签名、.p12 证书必须匹配，否则安装失败。upload.pgyer.com

集成 CI/CD：发包流程自动化

我们把蒲公英上传流程嵌入 CI/CD，让构建、上传、通知构成闭环。使用的是 API 2.0。pgyer.com

GitHub Actions 示例（Android）

name: Android Build + Pgyer Upload

on:
  push:
    branches: [ "develop" ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Setup Java
        uses: actions/setup-java@v3
        with:
          distribution: "temurin"
          java-version: "17"

      - name: Assemble Debug APK
        run: ./gradlew assembleDebug

      - name: Upload to Pgyer
        run: |
          curl -F "file=@app/build/outputs/apk/debug/app-debug.apk" \
               -F "_api_key=${{ secrets.PGYER_API_KEY }}" \
               https://upload.pgyer.com/apiv2/app/upload

PGYER_API_KEY 存在 GitHub Secrets 中；
构建完成后自动触发上传；
上传用的是 apiv2/app/upload 接口，返回 JSON 可用于后续处理。

Jenkins Pipeline 示例

pipeline {
  agent any
  stages {
    stage('Checkout') {
      steps { checkout scm }
    }
    stage('Build') {
      steps { sh './gradlew assembleDebug' }
    }
    stage('Upload to Pgyer') {
      steps {
        sh """
          curl -F "file=@app/build/outputs/apk/debug/app-debug.apk" \
               -F "_api_key=${PGYER_API_KEY}" \
               https://upload.pgyer.com/apiv2/app/upload
        """
      }
    }
  }
}

Jenkins Credentials 用来管理 PGYER_API_KEY，避免明文泄露；
Pipeline 成功执行后即可把包发送给蒲公英。

上传状态检测与构建校验

考虑到上传是异步的，我们在 CI 中加了一个轮询逻辑：

使用 getCOSToken 接口获取上传凭证和 COS 参数。pgyer.com
上传完文件后，用 buildInfo 接口查询构建状态。pgyer.com
构建成功返回后再通知测试组（比如发钉钉或邮件机器人）。

这种方式可以避免“构建完了但还没发布”的状态错乱。

版本管理与测试分发策略

我们在蒲公英上建立了以下管理策略：

渠道区分：不同测试组（如功能测试 / 兼容测试 /灰度测试）使用不同渠道。
版本标识：构建号 + 分支名 + 本地变更说明写在版本说明里，测试人员一看就知道是谁发的包。
过期机制：对已过时版本设置过期标记，防止测试人员安装旧包。
统计监控：后台查看下载量、安装量、终端设备类型，保证内测覆盖度。

这种策略让测试流程标准化，也让团队更清晰地知道“哪个版本测过了，哪个没测”。

风险与技术权衡

风险 / 挑战	我们的处理方式
HarmonyOS 签名不一致导致安装失败	强制校验 .hap 签名 + .p12 版本一致；测试签名流程后才批量发包。
API 上传失败 / 网络不稳定	使用预上传 getCOSToken、多次重试 + 错误重跑机制。
测试人员安装流程出问题	提供统一下载页 + 二维码 + 安装说明；测试组内部统一引导。
版本回滚复杂	在蒲公英后台标记旧版本 “过期” 或 “删除 buildKey”，保留历史但不混淆。

总结

使用 蒲公英 API 2.0，我们把内测包上传、分发整个流程纳入 CI/CD 管道，自动化、标准化。
支持 HarmonyOS (.hap + .p12)，解决了纯血鸿蒙应用的内测分发问题。
多渠道、多版本、版本管理清晰，测试覆盖可控。
风险点明确且可控，通过接口校验、轮询逻辑、过期策略保障流程稳定。

对一个需要频繁发包、多人测试、多平台协同的开发团队来说，这套方案既技术扎实，又非常实用。