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

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

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

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

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

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

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

引言

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

本地改代码
   ↓
手动点击构建
   ↓
导出 .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

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

第一步：写一个构建脚本

#!/bin/bash

echo "开始构建..."

hvigor assembleHap --mode release

echo "构建完成"

第二步：接入 CI（示例）

build:
  script:
    - ./build.sh

第三步：自动触发

git push → 自动构建

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

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

1、自动版本号

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

每个包唯一：

202604201930

解决：

版本混乱问题

2、环境隔离

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

示例

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

3、自动通知

echo "新版本构建完成"

可以接：

• Slack
• 邮件
• 企业微信

4、自动发布

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

测试不用再问你要包。

六、多端 CI/CD

在 HarmonyOS 中：

你必须考虑：

手机版本
TV 版本
Pad 版本

CI 设计

build_mobile:
  script: ./build_mobile.sh

build_tv:
  script: ./build_tv.sh

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

七、CI/CD + AI

想象一下：

AI 自动：

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

示例

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 才能做产品。