HarmonyOS NEXT 应用构建与后端部署流水线

发表于 分类于 ，
鸿蒙应用 hvigor 后台构建等待 BUILD SUCCESSFUL、Go 后端交叉编译部署、冒烟测试的完整流水线实践，以及真机调试命令备忘。

鸿蒙端 + Go 后端的项目，交付流程跑通之后固化成了一条流水线。核心诉求：改完代码，一条命令完成”构建 → 部署 → 冒烟”，不用在多个工具间来回切换。

整体流程

鸿蒙端与Go 后端部署流水线：构建、产物、上传、切换、冒烟及各步失败回滚点

1
2
3
4
代码改动
  ├─ 鸿蒙端：hvigorw.js assembleHap（后台构建，等 BUILD SUCCESSFUL）
  ├─ 后端：交叉编译 → SCP 上传 → systemd 重启
  └─ 冒烟：curl 关键接口，全 200 才算交付完成

鸿蒙端：后台构建 + 结果等待

DevEco 的 hvigor 构建可以直接命令行跑，关键是不要在前台干等，让它后台跑，轮询产物和退出码：

1
2
3
4
5
6
7
8
9
10
11
# 后台启动构建
cd /path/to/project
nohup node hvigorw.js assembleHap --mode module -p product=default > build.log 2>&1 &
echo $! > build.pid

# 等待构建结束（轮询进程 + 日志关键字）
while kill -0 $(cat build.pid) 2>/dev/null; do
  sleep 5
done

grep -q "BUILD SUCCESSFUL" build.log && echo "OK" || { echo "FAILED"; tail -50 build.log; }

两个实践：

  1. 以 BUILD SUCCESSFUL 为准，而不是退出码。hvigor 偶发退出码为 0 但实际构建结果存疑的情况，日志关键字是更可靠的判据；
  2. 失败时直接 tail 日志，hvigor 的错误信息（ ArkTS 类型错误、资源缺失）都在 log 里，不要重新跑一遍看输出。

产物路径固定：entry/build/default/outputs/default/entry-default-signed.hap，构建成功后直接装真机：

1
hdc install entry/build/default/outputs/default/entry-default-signed.hap

后端：交叉编译 + 原子部署

Go 服务部署到 Linux 服务器的标准动作：

1
2
3
4
5
6
7
8
# 本地（Windows）交叉编译，禁用 CGO 得到静态二进制
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -ldflags="-s -w" -o msgstackapi ./cmd/server

# 上传（保留旧版本号命名，不回滚时直接换启动文件）
scp msgstackapi user@server:/opt/msgstackapi/releases/msgstackapi-$(date +%Y%m%d%H%M%S)

# 服务器侧：软链切换 + 重启
ssh user@server "ln -sf /opt/msgstackapi/releases/msgstackapi-* /opt/msgstackapi/bin/msgstackapi && systemctl restart msgstackapi"

要点：

  • CGO_ENABLED=0：静态二进制，目标机不需要 glibc 版本匹配，杜绝”本地跑得好好的，服务器上起不来”；
  • 软链切换：新版本放 releases/ 带时间戳，bin/ 是指向当前版本的软链，回滚就是改软链 + 重启，秒级；
  • 重启后必须验证：systemctl is-active 看服务状态，journalctl -u xxx --since "1 min ago" 看启动日志，缺一不可。

冒烟测试：交付的最低门槛

部署完不验证等于没部署。冒烟集不用大，覆盖核心链路即可：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#!/bin/bash
BASE="http://127.0.0.1:8080/api"
fail=0

check() {
  code=$(curl -s -o /dev/null -w "%{http_code}" "$1")
  [ "$code" = "200" ] || { echo "FAIL $1 -> $code"; fail=1; }
}

check "$BASE/health"
check "$BASE/v1/messages?limit=1"
# ... 其他关键接口

[ $fail -eq 0 ] && echo "SMOKE PASS" || echo "SMOKE FAIL"

在服务器本机跑（127.0.0.1），排除网络因素，只验证服务本身活着。

一条命令串起来

项目根目录放个 deploy.sh，把上面三段串成一条命令，交付就从”半小时手工活”变成”一杯咖啡”：

1
2
3
4
5
6
7
8
9
10
11
#!/bin/bash
set -e

echo "[1/3] 构建鸿蒙端..."
bash scripts/build-hap.sh

echo "[2/3] 编译并部署后端..."
bash scripts/deploy-backend.sh

echo "[3/3] 冒烟测试..."
bash scripts/smoke.sh && echo "=== 交付完成 ==="

小结

流水线的价值不在自动化本身，而在于每一步都有明确的成功判据：BUILD SUCCESSFUL、软链切换成功、冒烟全 200。判据清晰，失败时才能第一时间定位在哪一环，而不是对着”好像没生效”的现象猜。