鸿蒙游戏 CI/CD：为什么你还在手动打包？

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

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

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，

在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

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

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

子玥酱 · 前端成长记录官 ✨

👋 如果你正在做前端，或准备长期走前端这条路

📚 关注我，第一时间获取前端行业趋势与实践总结

🎁 可领取 11 类前端进阶学习资源 （工程化 / 框架 / 跨端 / 面试 / 架构）

💡 一起把技术学"明白"，也用"到位"

持续写作，持续进阶。

愿我们都能在代码和生活里，走得更稳一点 🌱

文章目录

- 引言
- [一、你真的需要 CI/CD 吗？](#一、你真的需要 CI/CD 吗？)
- - 你是否遇到过：
- 二、手动打包，本质问题是什么？
- - 本质问题不是"慢"，而是"不可控"
- [三、CI/CD 到底解决了什么？](#三、CI/CD 到底解决了什么？)
- - 标准流程
- [四、最小可用 CI/CD](#四、最小可用 CI/CD)
- - 第一步：写一个构建脚本
  - [第二步：接入 CI（示例）](#第二步：接入 CI（示例）)
  - 第三步：自动触发
- [五、进阶：让 CI/CD 真正"好用"](#五、进阶：让 CI/CD 真正“好用”)
- - 1、自动版本号
  - 2、环境隔离
  - 3、自动通知
  - 4、自动发布
- [六、多端 CI/CD](#六、多端 CI/CD)
- - 你必须考虑：
  - [CI 设计](#CI 设计)
- [七、CI/CD + AI](#七、CI/CD + AI)
- - [AI 自动：](#AI 自动：)
  - 示例
- 八、为什么很多团队迟迟不做？
- - 常见借口：
- 九、一个真实对比
- - [没有 CI/CD](#没有 CI/CD)
  - [有 CI/CD](#有 CI/CD)
- 十、总结

引言

如果你现在还在这样发布鸿蒙游戏：

复制代码

本地改代码
   ↓
手动点击构建
   ↓
导出 .hap
   ↓
发给测试
   ↓
发现问题 → 再来一遍

那我可以很直接地说一句：

你不是在做开发，而是在"重复劳动"。

很多团队一开始都这样，直到某一天：

一天打包 10 次
不同人打出来的包不一样
测试找不到对应版本
紧急修复上线手忙脚乱

然后才意识到：

问题不在"打包"，而在"没有 CI/CD"。

在 HarmonyOS 的工程体系里：

CI/CD 不是锦上添花，而是基础设施。

一、你真的需要 CI/CD 吗？

先问你几个问题：

你是否遇到过：

"这个包是谁打的？"
"代码明明一样，为什么包不一样？"
"这个 Bug 是哪个版本引入的？"
"能不能回滚到昨天版本？"

如果你点头了：

你已经在为"没有 CI/CD"付出代价了。

二、手动打包，本质问题是什么？

很多人觉得：

"手动打包也能用，只是麻烦点。"

这其实是个误解。

本质问题不是"慢"，而是"不可控"

1、构建不可复现

复制代码

A 同事打的包 ≠ B 同事打的包

因为：

环境不同
配置不同
操作不同

2、流程不可追踪

复制代码

哪个版本对应哪个提交？

答不上来。

3、发布不可回滚

复制代码

线上炸了怎么办？

没有标准版本，只能重新打。

4、多端直接崩溃

在 HarmonyOS 中：

复制代码

手机 / TV / 平板

如果手动打包：

复制代码

3 倍工作量 + 3 倍风险

三、CI/CD 到底解决了什么？

一句话总结：

把"人做的事"，变成"系统做的事"。

标准流程

复制代码

代码提交（Git）
   ↓
自动构建（CI）
   ↓
自动测试
   ↓
自动打包
   ↓
自动发布（CD）

你不用再"手动点按钮"。

四、最小可用 CI/CD

不需要一上来就搞复杂系统。

第一步：写一个构建脚本

bash 复制代码

#!/bin/bash

echo "开始构建..."

hvigor assembleHap --mode release

echo "构建完成"

第二步：接入 CI（示例）

yaml 复制代码

build:
  script:
    - ./build.sh

第三步：自动触发

复制代码

git push → 自动构建

到这一步，你已经比 80% 的项目强了。

五、进阶：让 CI/CD 真正"好用"

1、自动版本号

bash 复制代码

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

每个包唯一：

复制代码

202604201930

解决：

复制代码

版本混乱问题

2、环境隔离

复制代码

dev（开发）
test（测试）
prod（线上）

示例

bash 复制代码

if [ "$ENV" == "prod" ]; then
  build_release
else
  build_debug
fi

3、自动通知

bash 复制代码

echo "新版本构建完成"

可以接：

Slack
邮件
企业微信

4、自动发布

bash 复制代码

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

测试不用再问你要包。

六、多端 CI/CD

在 HarmonyOS 中：

你必须考虑：

复制代码

手机版本
TV 版本
Pad 版本

CI 设计

yaml 复制代码

build_mobile:
  script: ./build_mobile.sh

build_tv:
  script: ./build_tv.sh

一次提交，自动生成多个包。

七、CI/CD + AI

想象一下：

AI 自动：

检查代码
生成测试用例
判断是否可以发布

示例

ts 复制代码

if (aiReview.isSafe(commit)) {
  deploy()
}

这就是：

智能 CI/CD

八、为什么很多团队迟迟不做？

常见借口：

1、"现在项目还小"：等变大就更难改。

2、 "先把功能做完再说"：技术债会爆炸。

3、"CI/CD 很复杂"：最小版本一天就能搞。

九、一个真实对比

没有 CI/CD

复制代码

开发 → 手动打包 → 测试 → 再改 → 再打包

时间：

复制代码

1 次发布 = 30~60 分钟

有 CI/CD

复制代码

提交代码 → 自动完成

时间：

复制代码

几分钟 + 无人值守

十、总结

如果你还在手动打包，本质是：

你把"系统问题"，当成了"个人操作"。

鸿蒙游戏为什么不能手动打包？

复制代码

不可复现
不可追踪
不可回滚
多端不可控

CI/CD 带来的改变是：

复制代码

自动构建
自动测试
自动发布
标准版本

在 HarmonyOS 的多端 + AI + 分布式场景下，这不是"优化"，而是：

唯一可行的工程方式。

最后：

手动打包只能做 Demo，CI/CD 才能做产品。