子玥酱 （掘金 / 知乎 / CSDN / 简书 同名）

大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出

我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

很多人做鸿蒙游戏时，对 CI/CD 的理解还停留在：

“写完代码 → 手动打包 → 手动上传”

小项目还能接受，但一旦进入团队协作或持续迭代，很快就会出现：

• 每个人打包结果不一致
• 版本管理混乱
• 回滚困难
• 多端发布极其麻烦
• 测试效率低

最后你会发现：

不是开发慢，而是交付链路太原始。

在 HarmonyOS 的生态中：

CI/CD 不只是“自动打包”，而是“持续交付系统”。

下面我们讲清楚：

鸿蒙游戏如何设计一套可落地的 CI/CD 方案（开发 → 构建 → 测试 → 发布）

一、先说结论

一套成熟的 CI/CD，需要解决 4 件事：

1、自动构建（Build）
2、自动测试（Test）
3、自动发布（Deploy）
4、版本可追踪（Versioning）

如果缺一个：

你的项目就不可持续迭代

二、最常见错误

手动流程

开发 → 本地打包 → 上传 → 测试 → 再改 → 再打包

问题：

• 极易出错
• 无法复现
• 浪费时间

没有环境区分

开发环境 = 测试环境 = 线上环境

一旦出问题：

无法定位

三、正确思路：流水线

CI/CD 本质是：

代码提交 → 自动触发 → 流水线执行

标准流程

Git Push
   ↓
CI 构建
   ↓
测试
   ↓
打包
   ↓
发布

四、第一步：代码管理

推荐结构

main（稳定版本）
develop（开发分支）
feature/*（功能分支）

示例流程

feature → develop → main → 发布

好处：

• 版本清晰
• 易回滚

五、第二步：自动构建

鸿蒙项目通常用：

hvigor / DevEco CLI

示例构建脚本

#!/bin/bash

echo "开始构建"

hvigor assembleHap --mode module -p product=default

echo "构建完成"

输出：

.hap / .app 包

CI 集成

build:
  stage: build
  script:
    - chmod +x build.sh
    - ./build.sh

每次提交自动构建。

六、第三步：自动测试

1、单元测试

test('score should increase', () => {
  expect(addScore(1, 2)).toBe(3)
})

2、UI 测试（ArkUI）

可以模拟：

点击
输入
页面跳转

3、CI 执行

test:
  stage: test
  script:
    - npm run test

目标：

每次提交都能验证正确性

七、第四步：自动打包

构建产物

debug 包（测试）
release 包（上线）

示例

hvigor assembleHap --mode release

可以区分：

dev / test / prod

八、第五步：自动发布

方式 1：上传测试平台

curl -F "file=@app.hap" https://test-platform/upload

方式 2：上传到应用市场

结合：

• 发布 API
• 自动版本号

示例流程

CI → 打包 → 上传 → 通知测试

九、第六步：版本管理

手动版本

1.0.0
1.0.1
1.0.2

容易混乱。

自动版本

VERSION=$(date +%Y%m%d%H%M)

示例：

202604181730

写入配置

{
  "versionName": "1.0.$VERSION"
}

每次构建唯一版本。

十、第七步：多端构建

鸿蒙游戏可能支持：

手机 / 平板 / TV

CI 方案

build_mobile:
  script: ./build_mobile.sh

build_tv:
  script: ./build_tv.sh

输出不同包。

十一、第八步：资源与 AI 模型更新

问题

游戏不仅有代码，还有：

资源（图片 / 音频）
AI Prompt / 模型

解决方案

资源版本

{
  "resourceVersion": "20260418"
}

CI 发布资源

upload_to_cdn assets/

AI 配置更新

{
  "npc_prompt": "守卫角色..."
}

支持热更新。

十二、第九步：通知与回滚

通知

echo "新版本发布完成" | slack

回滚

回退到上一个版本

必须支持。

十三、完整 CI/CD 架构

开发（Git）
   ↓
CI（构建）
   ↓
测试（自动）
   ↓
打包（多端）
   ↓
发布（平台 / CDN）
   ↓
通知（团队）

十四、为什么鸿蒙游戏更需要 CI/CD？

因为复杂度更高：

1、多端

一个改动 → 多设备验证

2、AI

Prompt / 模型变化

3、分布式

设备协同测试

手动流程根本撑不住。

十五、常见错误

1、只做构建，不做测试

2、没有版本管理

3、手动发布

4、不区分环境

5、不支持回滚

总结

鸿蒙游戏 CI/CD 的核心：

自动构建
+ 自动测试
+ 自动发布
+ 多端支持
+ 版本管理

在 HarmonyOS 的生态中，这套体系带来的不是“效率提升”，而是：

从“手动发布”，升级为“持续交付”。

最后：

没有 CI/CD，你只能做 Demo；有了 CI/CD，你才能做产品。