👋 你好，欢迎来到我的博客！我是【菜鸟学鸿蒙】
   我是一名在路上的移动端开发者，正从传统“小码农”转向鸿蒙原生开发的进阶之旅。为了把学习过的知识沉淀下来，也为了和更多同路人互相启发，我决定把探索 HarmonyOS 的过程都记录在这里。
  
  🛠️ 主要方向：ArkTS 语言基础、HarmonyOS 原生应用（Stage 模型、UIAbility/ServiceAbility）、分布式能力与软总线、元服务/卡片、应用签名与上架、性能与内存优化、项目实战，以及 Android → 鸿蒙的迁移踩坑与复盘。
  🧭 内容节奏：从基础到实战——小示例拆解框架认知、专项优化手记、实战项目拆包、面试题思考与复盘，让每篇都有可落地的代码与方法论。
  💡 我相信：写作是把知识内化的过程，分享是让生态更繁荣的方式。
  
   如果你也想拥抱鸿蒙、热爱成长，欢迎关注我，一起交流进步！🚀

前言：CI/CD 的本质不是“更酷”，是“少挨骂”🙂

我说句大实话：

• 自动构建解决“我能不能稳定产出包”
• 自动化测试解决“这包敢不敢给人装”
• 发布流程解决“出了事到底谁背锅（以及怎么不背锅）”😅

鸿蒙这套链路里，真正的核心工具其实就俩：

• Hvigor/hvigorw：负责构建任务（clean/assembleHap/assembleApp/assembleHar/assembleHsp 等）
• 测试执行：既可以直接用 hvigorw 的 test / onDeviceTest（Instrument/Local Test） ，也可以在 OpenHarmony 侧用 xDevice 做更系统的测试调度与报告产出

1) 自动构建流程：让流水线“自己会打包”，别让人当机器人🤖➡️🧑‍💻

1.1 构建环境的关键点（鸿蒙这边真有“硬要求”）

官方“命令行构建/搭建流水线”指南里明确提到：

• 支持 Windows/Linux/macOS（示例以 Linux 为主）
• JDK 17（只支持 JDK 17）
• 命令行工具中可调用 Hvigor 任务，适用于 CI 场景

我踩过的坑：JDK 版本不对，构建报错能把你日志刷到眼花，但你还以为是代码问题🙂

1.2 hvigorw 一句话打包（你先把“手点 IDE”戒了）

Hvigor 命令行任务官方列得很清楚：

• clean 清理产物
• assembleHap 构建 Hap
• assembleApp 构建 App（通常是最终 app 包）
• assembleHar/assembleHsp 构建共享包
  并且可以用 -p buildMode=debug|release、-p product=xxx、-p module=xxx@target 等参数精确控制构建

最常用的 CI 构建脚本骨架（bash 示例）：

#!/usr/bin/env bash
set -euo pipefail

# 1) 安装依赖（按你的项目实际用 ohpm/pnpm 配置）
# ohpm install  /  pnpm install ...

# 2) 清理 + 构建（release）
hvigorw clean
hvigorw assembleApp -p buildMode=release --no-daemon --analyze=normal

小心机：--analyze=normal/advanced 可以开启构建分析，出报告辅助定位“构建为什么慢”
CI 场景我一般会加 --no-daemon，减少“环境遗留状态”导致的玄学问题😅

2) 多设备打包：不是“打多个包”，是“同一套代码，产出不同产品”📦📦📦

2.1 用 product（品类）区分设备/渠道（最稳、最工程化）

Hvigor 支持 -p product={ProductName} 指定 product 编译构建目标；默认是 default
这意味着你完全可以在工程的配置里定义：

• phone（手机包）
• tablet（平板包）
• car（车机包）
• market / internal（不同渠道包）

CI 里多品类构建（示例）：

# 手机
hvigorw assembleApp -p buildMode=release -p product=phone

# 平板
hvigorw assembleApp -p buildMode=release -p product=tablet

2.2 用 module 精确构建（减少构建时间，少等就是赚😄）

-p module= {ModuleName}@{TargetName} 配合 --mode module 可以只构建指定模块（多个模块逗号分割）
适合场景：

• 只改了一个 HAP/HAR/HSP，不想全量构建
• PR 构建想快点出结果

hvigorw assembleHap --mode module \
  -p buildMode=debug \
  -p module=entry@default

3) 自动化测试接入：别让测试同学当“人肉回归工具”😅

3.1 直接用 hvigorw 跑测试（最快落地）

官方文档给了很明确的命令：

• hvigorw test：Local Test
• hvigorw onDeviceTest：Instrument Test（从 Hvigor 4.3.0 开始支持）
  并支持 -p module、-p scope=suite#method、-p coverage=true|false，还说明了报告输出目录

CI 示例：跑设备测试 + 覆盖率

# 设备插桩测试（跑指定模块）
hvigorw onDeviceTest -p module=entry -p coverage=true

# 本地单元测试（可选）
hvigorw test -p module=entry -p coverage=true

3.2 OpenHarmony 大规模测试调度：xDevice（适合“多设备矩阵”）

如果你们是 OpenHarmony 或者要做“设备农场”那种规模化回归，xDevice 更像“总控台”。
xDevice 仓库说明里提到：执行后会在控制台打印日志，并在 -rp 指定目录生成执行报告（不指定则用默认目录），报告目录结构也有说明

我个人建议：

• 小团队/单应用：先 hvigorw 测试跑起来
• 多设备/多系统版本：再引入 xDevice 做调度和统一报告

4) 发布流程设计：把“发版”从手艺活变成流程活🧭

4.1 一个我很推崇的发布分层（不花哨，但抗揍）

阶段 1：PR 校验（快）

• lint/format（可选）
• build debug（或最小构建）
• 跑关键单测

阶段 2：主干集成（稳）

• assemble release
• onDeviceTest（核心用例）
• 输出 artifacts（app/hap/日志/报告）

阶段 3：预发布（可观测）

• 灰度包（internal channel）
• 指标验证（启动、崩溃率、关键埋点）

阶段 4：正式发布（可追责）

• 打 tag
• 生成 release notes
• 固化包校验（hash）
• 审批/回滚策略

4.2 签名与产物管理：别把证书当成“共享账号密码”😨

官方“搭建流水线”指南里把“准备签名所需文件、对 HAP 进行签名”等作为流水线步骤的一部分
我的经验建议很现实：

• 证书/密钥放 CI 的 Secret（别进仓库）
• 产物按 “分支-commit-时间” 命名归档
• 报告、日志、trace 一起存（出了问题才有证据链）

一份“能跑起来”的 GitHub Actions 示例（你改变量就能用）🛠️

你要是用 Jenkins/GitLab，我也能按同逻辑给你换成 Jenkinsfile/.gitlab-ci.yml（你回我平台就行🙂）

name: Harmony CI

on:
  push:
    branches: [ "main" ]
  pull_request:

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

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

      - name: Build Release App
        run: |
          hvigorw clean
          hvigorw assembleApp -p buildMode=release --no-daemon --analyze=normal

      - name: Run Instrument Tests
        run: |
          hvigorw onDeviceTest -p module=entry -p coverage=true

说明：hvigorw onDeviceTest 的参数、coverage、报告路径等，官方写得非常细

常见翻车点（我替你提前骂一遍😅）

1. 构建环境不一致：JDK 版本、Node/依赖源、缓存策略一乱，CI 就开始“今天能过明天不过”
2. 多 product 没做隔离：同名产物覆盖、不同设备包混发（这锅背起来很重）
3. 测试只跑一台设备：分布式/多形态问题上线才爆
4. 没有报告归档：出了问题只剩一句“我本地没问题”🙂
5. 构建慢却不分析：Hvigor 的 analyze 能出报告，你不用它就像开车不用仪表盘

结尾：CI/CD 搞好了，你不是更忙，而是终于能下班😄

鸿蒙 CI/CD 真正的爽点是：

• 你提交代码后，系统自动给你一套“可信结果”
• 包、报告、日志都在
• 测试覆盖清清楚楚
• 发版流程可追溯、可回滚

不夸张地说：这是把“工程质量”从人的记忆力，交给流程的确定性。

📝 写在最后

如果你觉得这篇文章对你有帮助，或者有任何想法、建议，欢迎在评论区留言交流！你的每一个点赞 👍、收藏 ⭐、关注 ❤️，都是我持续更新的最大动力！

我是一个在代码世界里不断摸索的小码农，愿我们都能在成长的路上越走越远，越学越强！

感谢你的阅读，我们下篇文章再见～👋

✍️ 作者：某个被流“治愈”过的 移动端 老兵
📅 日期：2025-11-05
🧵 本文原创，转载请注明出处。