企业官网建设流程全解析

掌握 Hvigor 命令行构建、搭建 Jenkins/GitLab CI 流水线、落地多环境配置与自动化测试、实现一键签名打包发布

一、前置思考：从"手动发版"到"流水线交付"

1.1 手动发版的痛点

核心认知：手动流程的每一步都是不确定性的来源——环境差异、漏测、人为失误。
CI/CD 的价值不是"快"，而是确定性：同样的代码，永远产出同样的产物。

1.2 CI/CD 的价值

二、核心原理：流水线阶段

2.1 标准流水线

代码提交 → 触发流水线 │ ├─ Stage1 静态检查: Lint / 代码规范 ├─ Stage2 单元测试: 关键模块单测 ├─ Stage3 构建: Hvigor 命令行出包 ├─ Stage4 自动化测试: UI/性能压测 ├─ Stage5 质量门禁: 崩溃率/体积/性能阈值 ├─ Stage6 签名打包: 自动签名 ├─ Stage7 发布: 上传商店/分发平台 └─ Stage8 通知: 结果推送团队

2.2 流水线设计的核心原则

三、源码/API 深度解析：核心能力

3.1 Hvigor 命令行构建

# 命令行构建（CI 无 UI 环境）hvigorw clean# 清理hvigorw assembleHap# 构建 HAPhvigorw assembleHap--modemodule-pproduct=default hvigorw signHap# 签名hvigorw--sync# 同步工程# 常用参数hvigorw assembleHap--parallel# 并行hvigorw assembleHap--daemon# 守护进程hvigorw assembleHap--modemodule# 模块级hvigorw assembleHap-pbuildMode=release# 构建模式

CI 关键：命令行构建必须可重复、无交互——所有参数通过命令行/配置文件传入。

3.2 多环境配置

不同环境（debug/test/release）需要不同配置：

// build-profile.json5 多环境 { "app": { "products": [ { "name": "dev", "signingConfig": "dev_sign", "compatibleSdkVersion": "5.0.0(12)", "runtimeOS": "HarmonyOS", "buildModeSet": [{ "name": "debug" }] }, { "name": "test", "signingConfig": "test_sign", "buildModeSet": [{ "name": "release" }] }, { "name": "release", "signingConfig": "release_sign", "buildModeSet": [{ "name": "release" }] } ] } }

环境矩阵：

3.3 自动化测试集成

// 单元测试（ohosTest）import{describe,it,expect}from'@ohos/hypium';exportdefaultfunctionorderTest(){describe('OrderDomainTest',()=>{it('calc_total_correct',0,()=>{consttotal=calcOrderTotal([100,200,300]);expect(total).assertEqual(600);});it('discount_apply',0,()=>{consttotal=calcOrderTotal([100],0.8);expect(total).assertEqual(80);});});}

# 命令行跑测试hvigorwtesthvigorw ohosTest

CI 测试分层：

3.4 签名管理

四、企业级实战：流水线搭建

4.1 Jenkins / GitLab CI 架构

Git 提交 (Merge Request) │ 触发 webhook ▼ CI Runner (构建机) ├─ Stage1 lint (静态检查) ├─ Stage2 unit test (单测) ├─ Stage3 assemble (Hvigor 构建) ├─ Stage4 ui test (UI 自动化) ├─ Stage5 perf gate (性能门禁) ├─ Stage6 sign (自动签名) └─ Stage7 publish (发布 + 通知)

4.2 质量门禁矩阵

4.3 多版本并行构建

同一时间多个分支同时构建: develop 分支 → dev 包 (每日) release/1.3 分支 → test 包 (提测) master 分支 → release 包 (发布) hotfix 分支 → 热修包 (紧急)

并行策略：

• 每个 MR 触发独立流水线；
• 分支合并前必须门禁全绿；
• 发布分支锁定（只允许合并经过验证的代码）。

4.4 持续交付闭环

开发 → 提测包(自动) → 测试通过 → 灰度包(自动) → 灰度监控(崩溃/性能) → 全量发布(自动) → 回滚预案

五、排查与优化：流水线效率

5.1 流水线瓶颈定位

5.2 高频坑点速查

• 构建是否可重复（无交互/无本地依赖）？
• 证书/密钥是否安全存储（不进代码库）？
• 是否按环境分离了配置？
• 门禁是否前置（便宜的先跑）？
• 单测是否覆盖关键模块？
• 性能门禁是否有基线对比？
• 构建产物是否带版本指纹？
• 是否支持一键回滚？
• 流水线是否并行化？
• 通知是否及时（失败即提醒）？

六、总结与进阶

6.1 收益模型（参考实测）

6.2 工程规范

1. 一切可脚本化：构建/测试/签名/发布全部脚本化；
2. 门禁强制：质量门禁是发布的唯一通行证；
3. 环境隔离：dev/test/release 严格隔离；
4. 可追溯：每个产物对应代码提交哈希；
5. 持续演进：流水线本身纳入版本管理。

6.3 进阶方向

• 流水线即代码：Jenkinsfile/GitLab CI 配置入库；
• 容器化构建：Docker 统一构建环境；
• 性能门禁自动化：压测脚本接入（第 41 篇联动）；
• 自动发版机器人：版本/更新日志自动生成。

附：Demo 演示说明