让Android走进CI/CD流水线

在上一篇文章中，我们探讨了自动化：如何以编程方式创建和管理Android环境。在第二篇中，我们讨论了规模化：共享基础设施如何让开发者和测试任务更容易访问这些环境。

本文聚焦下一步：将这些环境直接集成到CI/CD流程中。

许多CI/CD系统已经实现了软件交付过程的自动化，从构建应用或Android镜像，到触发测试和报告结果。然而，Android执行环境往往仍游离于工作流之外。以下是一些常见的脱节现象：

• 应用可以自动构建，但在验证开始前，仍需人工连接设备。
• 当所需的Android环境无法提供给流水线时，Pull Request会停留在手动阶段。
• 某项测试在工作站上通过，却在另一台机器上失败，原因是底层环境不一致。

这正是CI/CD集成所要弥合的鸿沟。借助Anbox Cloud，Android执行环境成为流水线可按需调用的资源之一。整个流程可以自动请求所需环境、部署产物、启动验证、收集结果，并在任务完成后释放资源。

Android不再被视作流水线的附属组件，而是深度融入自动化软件交付过程。

本文中，”Android执行环境”指运行和验证应用或系统的Android实例，包括Android镜像、配置、分配的资源及测试设置。

将Android纳入工作流程

CI/CD流水线建立在可重复性的基础之上。一次变更产生一个制品，测试基于明确的输入条件运行，流水线记录足够的信息以供复盘。

执行环境本身就是这一过程的一部分。CI/CD流水线早已能够按需调配临时资源，如容器、虚拟机、数据库和服务。引入Anbox Cloud后，Android执行环境可以作为另一种资源由流水线按需申请。

无需再将物理设备或本地模拟器作为前置依赖。流水线只需请求一个具有已知镜像和配置的Android环境，完成制品部署、验证执行、证据收集，最后释放资源即可。

需要注意的是，Anbox Cloud并不负责构建Android应用或平台，这部分工作仍由现有的构建系统承担。它的职责是提供一个可通过编程方式管理、生命周期可重复的Android执行环境。

典型的Android流水线

尽管具体工具链各不相同，但整体工作流基本一致。首先，流水线需要生成或拉取待验证的制品。对于应用团队而言，这可能是一个APK文件；对于平台团队而言，则可能是一个完整的Android或Android Automotive OS镜像。

通常情况下，在请求预定义环境之后，流程会依次完成：部署制品、准备测试数据、建立连接（例如通过ADB）。一切就绪后，在销毁环境之前，流水线需收集测试报告、日志、截图、崩溃数据和性能指标。

每个环节都应当清晰明确。流水线必须记录：测试了哪个制品、使用了哪个Android环境、应用了何种配置、生成了哪些输出。

缺少这些上下文信息，自动化虽能提速，却无法提升结果的可靠性。

可重复性比单纯自动化更重要

能够自动启动Android环境固然实用，但每次都能稳定启动同一个环境才更有价值。

如果每次运行的Android版本不一致、某些设置被手动修改、缓存数据干扰了测试结果，或者旧版应用残留其中，那么得到的结果很难令人信赖。将上述输入条件明确化，能够有效减少手动配置失误，提升可重复性。

Android镜像、应用制品、实例资源、显示设置、测试输入和预期输出，都可以与某次特定执行绑定。工作流还可以等待已知状态，而不是依赖随机延迟或对”环境就绪”的主观猜测。

一个脚本会说：”启动Android并运行这个测试。”而一个可重复的流水线会说：”用这个明确定义的环境，针对这个制品，执行这个版本的测试，输入这些参数，并保存足够的证据来说明结果。”

当某个故障阻塞发布时，团队需要的是第二种模式。

保留证据，而非冗余基础设施

临时环境的优势在于每次运行都能从干净状态开始，但销毁环境并不意味着可以丢弃调试所需的信息。

当验证失败时，流水线应在释放资源前收集相关诊断数据。同时，还应记录环境定义，以便工程师后续复现相同条件。在某些情况下，暂时保留一个实例供交互式排查也是可取的。

目标并不是无限期保留所有失败的实例，而是遵循一个更合理的原则：默认保留证据，仅在能带来额外价值时才保留环境。

这样一来，既保持了流水线的效率，又让团队拥有足够的信息来分析和复现故障。

结语

将Android执行环境集成到CI/CD流水线中，意味着消除人为干预的瓶颈、提升测试的可重复性、并确保每个构建都有据可查。借助Anbox Cloud，Android环境不再是孤立的资源，而是流水线中可按需申请和释放的标准化组件。

这不仅是一次技术升级，更是一种工程理念的转变：让Android与你的自动化交付流程真正融为一体。

关注微信号：智享开源 ，及时了解更新信息。

原文链接：https://ubuntu.com//blog/android-belongs-in-your-ci-cd-pipeline