3. 持续集成核心概念
在嵌入式UI开发中，代码提交往往涉及界面逻辑、驱动适配、资源文件与构建脚本的同步变更。如果这些变更长期分散在各自分支上，直到发布前才合并验证，缺陷就会在集成阶段集中爆发。持续集成（Continuous Integration，CI）正是为了解决这一问题而提出的工程实践：开发者频繁地将代码合入主干，每次合入都自动触发构建与测试，从而尽早发现集成错误。
3.1 CI的定义与原则
持续集成是一种软件开发实践：团队成员频繁地将工作成果集成到共享主干，通常每人每天至少提交一次；每次提交都通过自动化构建和自动化测试进行验证，使集成错误能够在数分钟内被定位和修复。对于嵌入式UI项目，CI 还需要覆盖交叉编译、资源打包、模拟器或硬件在环测试等环节。
CI 的落地需要遵循若干基本原则：
- 单一可信源：所有代码、构建脚本、配置和资源都纳入版本控制，主干是唯一可信的集成基线。
- 频繁提交：小步提交，降低单次集成的冲突范围和排查难度。
- 自动化构建：从拉取代码到产出可烧录镜像，全过程无需人工干预。
- 自动化验证：单元测试、静态检查、UI 快照测试等随构建自动执行。
- 快速反馈：构建与测试结果应在数分钟到十几分钟内反馈给提交者。
- 失败即修复：主干构建失败时，优先修复而不是继续叠加新功能。
- 可重复与可追溯：每次构建都有唯一编号，产物可追溯到具体提交。
3.2 CI流水线组成
一条典型的嵌入式UI CI流水线通常由触发、准备、构建、测试、制品归档和通知六个阶段组成。下图展示了各阶段之间的数据流与依赖关系，其中构建阶段会同时产出固件镜像和UI资源包，测试阶段则分别面向主机侧逻辑与目标板行为。
3.3 版本控制与分支策略
版本控制是CI的地基。没有统一的代码仓库和清晰的分支模型，自动化构建就无从谈起。嵌入式UI项目通常包含应用层、中间件、BSP、UI资源和构建脚本，建议采用单一仓库（Monorepo）或少量仓库配合子模块的方式管理，确保一次提交能同时覆盖界面与底层适配的变更。
常见的分支策略有三种：
| 策略 | 主干用途 | 分支方式 | 适用场景 |
|---|---|---|---|
| 主干开发 | 始终可发布 | 短生命周期特性分支，当天合入 | 团队成熟、测试覆盖率高 |
| Git Flow | 稳定发布 | develop/feature/release/hotfix | 版本节奏固定、多版本并行 |
| GitHub Flow | 随时可部署 | feature分支 + Pull Request | 持续交付、Web或快速迭代项目 |
对于嵌入式UI，推荐“主干开发 + 短特性分支”为主，发布版本通过标签（tag）固化。每次向主干合并都触发完整流水线，特性分支则触发快速检查，以平衡反馈速度与资源消耗。
3.4 构建自动化与制品管理
构建自动化要求把“人脑中的构建步骤”变成可执行脚本。嵌入式UI项目通常需要交叉编译工具链、Qt/ LVGL等UI框架、资源转换工具和打包脚本。以下是一个简化的CI构建脚本示例：
#!/bin/bash
set -e
# 1. 准备工具链
export PATH=/opt/toolchain/bin:$PATH
# 2. 配置与编译
cmake -B build -DCMAKE_TOOLCHAIN_FILE=arm-linux.cmake
cmake --build build -j8
# 3. 资源打包
python3 tools/pack_ui.py --input res/ --output build/ui.pak
# 4. 生成镜像
mkimage -A arm -O linux -T firmware -d build/app build/firmware.bin
# 5. 归档制品
cp build/firmware.bin build/ui.pak artifacts/
制品管理是CI容易被忽视的一环。每次构建产出的固件镜像、UI资源包、测试报告和符号表都应上传到制品库，并以“提交哈希 + 构建编号”命名，例如 firmware-abc1234-1024.bin。这样测试、发布和问题回溯都能精确定位到某一次构建。
3.5 案例与常见误区
某智能家居面板项目早期采用“每周合并一次”的方式，UI团队与驱动团队各自开发，结果每次合并都要花两天解决冲突，且经常出现界面卡死、触摸无响应等问题。引入CI后，团队改为每天至少合并一次，主干每次提交自动交叉编译并运行UI冒烟测试，构建时间控制在12分钟以内。三个月后，集成缺陷数量下降约七成，发布前的“救火”时间显著缩短。
常见误区包括：
- 把CI当成“有构建服务器”：只配置了自动编译，却没有自动化测试和失败阻断，缺陷依然会流入主干。
- 分支长期不合并：特性分支存活数周，合并时冲突巨大，违背持续集成初衷。
- 构建太慢：全量构建超过30分钟，开发者不愿等待，反馈闭环失效。应引入增量编译和缓存。
- 制品无追溯：测试发现的缺陷无法对应到具体提交，排查成本高。
- 主干失败仍继续提交：破坏“失败即修复”原则，导致流水线长期红灯。
总结来看，持续集成的核心在于：以版本控制为单一可信源，以短分支和频繁提交保持集成粒度，以自动化构建和测试提供快速反馈，以制品管理保证可追溯。这四者共同构成嵌入式UI项目持续集成的基石，也为后续的自动化测试与持续交付打下基础。