系列文章《鸿蒙开发从入门到专家》第 37 篇 · 专家
鸿蒙工程的"出包"流程一旦多人协作就开始崩：签名密钥谁保管、HAP 给谁测、灰度比例怎么调、Bug 复现要哪个 HAP。问题不在 DevEco Studio 工具不够好，而在没有把流程变成流水线工程。
这一篇按"流水线即代码"的思路，把一个典型鸿蒙应用从代码提交到灰度发布的 CI/CD 全过程拆开讲。看完你应该能把现有流程改成可度量、可回滚、可监控的状态。
一、流水线架构总览
先给出全流程图，后面再展开每一段：
Git 推送 单元测试 静态扫描 构建
提交 ────► Pre-MR ────► dev 分支集成 ────► Lint/类型/SCA ────► HAP 构建
│ │
│ ▼
│ 自测包 (每日构建)
│ │
▼ ▼
MR 检查 测试包 (灰度前)
Code Review │
流水线 lint ▼
QA 包
│
▼
生产灰度
不同环境的产物可以分别归档，测试 / 灰度 / 线上互不污染。这是一条标准的"多产物多环境"流水线。
二、签名与物料管理
签名密钥是企业生产资料，必须严格管理：
1. 物料分级
2. 流水线变量管理
以 GitLab CI 为例：
# .gitlab-ci.yml
variables:
SIGNING_KEYSTORE: ${CI_JOB_TOKEN_VAULT} # 由 Vault 插件注入
SIGNING_KEY_ALIAS: ${VAULT_KEY_ALIAS}
HMAC_PROFILES: ${VAULT_HMAC_PROFILE}
HMAC_KEYSTORE_PASS: ${VAULT_KEYSTORE_PASS}
加密后不会落盘，CI 任务执行时可解密，结束后清理。
3. 签名校验环节
流水线最后一步必须校验产物：
# 校验签名哈希
hdc shell bm install -p build/entry-signed.hap -r
sha256sum build/entry-signed.hap | tee build/SHA256SUMS
把 SHA256 也存进产物清单，下次发布前能比对校验。
三、构建：并行、多包、依赖缓存
鸿蒙工程的构建是 DevEco Studio + hvigor 完成的，CI 上必须能复用其能力。DevEco 的 CLI hvigorw 是入口：
./hvigorw clean -p product=default
./hvigorw assembleHap -p product=default -p buildMode=release -p sign=true
1. 多模块并行
组件化项目里可能有 8 个 features 同步构建，串行需要 10 分钟，并行能压到 2 分钟。CI 用 parallel 矩阵：
build-features:
stage: build
parallel: 8
script:
- ./hvigorw :feature-${CI_NODE_INDEX}:assembleHap
artifacts:
paths:
- feature-${CI_NODE_INDEX}/build/
2. 依赖缓存
node_modules、.hvigor 缓存、build-cache 一定要在流水线间复用，否则每次拉 deps 重编译要几十秒。
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- node_modules/
- .hvigor/cache/
- .gradle/caches/
3. 构建产物归类
每个产物单独上传到内部分发平台（如蒲公英、企业自建 CDN）方便测试。
四、测试：单元、UI、兼容性
测试金字塔是公认的：
端到端 E2E
───────────
集成测试
───────────────
单元测试
─────────────────
1. 单元测试
鸿蒙的单元测试是 @ohos/hypium 框架。可在 CI 里跑：
hvigorw :module-test:clean :module-test:test
覆盖率至少 30%，核心模块 70%。配合 nyc/coverage 上传到 codecov 之类的平台。
2. UI 自动化
hypium 配合 DevEco Testing，也能做基于 UI Automator 的 E2E 流程。建议接入：
闪退 / 白屏自动检测。
关键流程（登录 → 首单 / 注册 → 进首页）跑通截图比对。
兼容多个 HarmonyOS 版本。
3. 多设备 / 多分辨率
鸿蒙设备类型从手机、平板到车机、手表差异大。CI 最好接入云测服务（华为 AppGallery Cloud Test 或自建 device farm），关键机型跑一遍构建产物。
五、发布与灰度
发布是一次"流水线 + 审核 + 平台操作"的动作，建议设计成：
1. 灰度等级
每级之间有观察期（建议 24-72 小时），用 AppGallery Connect 的版本管理配置。
2. 配置化灰度
不要写死在代码里。后端下发一份灰度表：
{
"version": "1.2.0",
"phase": "internal",
"deviceIdPrefix": ["0xCAFE", "0xBABE"],
"minTimeAfterRelease": "2026-09-10T08:00:00Z",
"maxFailRatePercent": 2,
"autoRollbackOnError": true
}
客户端启动时读取，符合条件就走新版本，否则走老逻辑。
3. 回滚预案
不写回滚的灰度不算灰度。设计三类回滚：
代码回滚：紧急时把主干 revert 到上一个稳定 tag。
配置回滚：服务端一键关闭新版本开关，客户端走回老逻辑。
包体回滚：把商店版本回滚到上一个已上架版本。
4. 应用市场操作
鸿蒙的应用市场是 AppGallery Connect。上架包要符合规范：
必填素材：图标、截图、视频。
元数据：分类、权限使用说明、隐私协议链接。
自检：AAB / HAP 扫描通过。
CI 里加一道上架前合规校验：
# 伪代码
python3 scripts/validate_publish.py \
--version $VERSION \
--changelog docs/changelogs/$VERSION.md \
--screenshots build/screenshots/
校验不通过则阻塞。
六、监控集成
流水线产物上线后，效果要看：
崩溃率：hiAppEvent 上报 → DataBuddy/GrowingIO。
ANR 率：同上。
包安装成功率：服务端发版后 1 小时内的安装/启动比。
首屏时间：端上 SDK 自动采集。
CI 应该把监控阈值和流水线串起来：监控到崩溃率超过阈值，自动触发版本回滚工单。
七、案例：一家中型团队的流水线
团队规模：10 个鸿蒙开发 + 5 个 QA + 2 个运维。
工具链：
流水线每日触发 ~50 次，每次平均 8 分钟（之前是 35 分钟）。签名前置、产物归档、灰度配置自动注入，所有动作可追溯。
常见报警有：
构建失败率上升。
单组件测试通过率掉到 95% 以下。
上架资质校验不过。
灰度阶段崩溃率超阈值。
每个报警有 oncall 责任人，处理时长有 SLA。
八、流水线即代码
整个 CI/CD 过程要"代码化"：
Jenkinsfile/.gitlab-ci.yml提交进仓库。灰度配置、产品需求与代码同步改动。
监控规则、报警阈值都从配置中心拉。
不要让运维记一份"流水线说明书"。任何改动都要走 MR review，避免一台机器的配置被个人记忆锁死。
小结
CI/CD 不是让运维玩新工具，是给整个团队一套"可重复、可回滚、可计量"的发布秩序。要点：
签名密钥：集中管理，签名校验自动化。
构建：并行 + 缓存 + 多产物归档。
测试：金字塔覆盖，多机型验证。
发布：灰度等级 + 回滚预案 + 合规校验。
监控：崩溃率、ANR、安装成功率。
代码化：流水线和配置全部走版本管理。
下一篇我们要谈的是上线后的事情——怎么用监控系统看见应用里发生的一切：日志、Crash、性能、用户路径，都汇集到统一的可观测平台。
参考阅读
鸿蒙开发者文档《hvigor 编译命令行》
鸿蒙开发者文档《AppGallery Connect 上架流程》
《Continuous Delivery》（Jez Humble，思路可借鉴）
《Site Reliability Engineering》（Google，监控报警）