我负责领导一名小型团队，负责开发一款fleet管理应用，总共4人，分为2个backend开发者，1个移动开发者以及我自己处理backend和基础设施。我的backend配置如下：githubactions用于CI，aws为separate staging和production环境，PR合并后自动将应用发布到staging环境，开发环境中使用真正的postgres实例来进行集成测试，生产环境采用canary发布，若错误率超过2%则会自动回滚。获得pipeline配置正确需要约6个月，之后我自豪地告诉大家。

部署事件会在slack上发布，pull request会附带测试覆盖率报告，没有人再手动发布到生产环境。

移动应用的情况则不同，安卓apk在pipeline中正常构建，之后会上传到内部测试版本库中的google play，之后过程如下：团队成员在他们的手机上打开测试版本，15分钟后浏览主页面，并将状态同步记录到slack。这样就完成了测试。

我们曾经在6个月内发布了2次失败的版本，当时我们依赖的测试流程。第一次是，因为更新了task 初始化的方式，我的android app偶然地创建了多个工作请求因为没用kepp policy，这样导致设备上的sync task会在一段时间后被触发3-4次，导致用户开始抱怨电池耗尽。15分钟的测试过程无法检测出这样的问题，而且只能通过更新应用来修复。

第二次是因为更新了安卓的13版本，改變了 POST_NOTIFICATIONS 权限对话框的展示点。当我们更新了SDK为33时，权限对话框在升级流程中开始在一个不同的场景展示，而对新安装的设备来说会在安装流程中正確展示。对来自安卓12的更新设备来说，这会在设置完成后展示，而因为缺乏对这个通知权限的上下文，对话框的关闭率是很高的，我们因此也失去了对一个大部分用户的通知权限。我们花了3个星期才在我们的分析中发现了这种模式。

约一年前，我加入了移动测试到pipeline中，使用一款普通英语编写的流程来跑测试来完成测试流程，在这个流程中，流程会在设备的模拟器中使用AI视觉来模拟人工手动操作。测试流程如下：测试流程会描述如下：完成新员工的onboarding流程，接收系统弹出的提示，添加车辆，分配到司机，验证车辆在物流地图上是否可见。开发者按照测试流程编写测试步骤，就像给新员工描述同样的流程一样。此工具将使用AI视觉替代元素选择来与界面进行交互。

这样会在CI配置中建立一个单独的pipeline，跑完这个流程后会创建模拟设备，并跑通过的流程在PR中，会将测试结果回传到PR。如果测试结果返回失败，PR将不能合并到主分支。

末次测试结果在之前这10个月中发现的7个问题中。最近一次就是上个冲刺：我对导航进行了重构，然而完成添加车辆的流程后，会被重定向到错误的界面而不是预期的物流地图界面。测试工具捕捉到了这个bug，PR被flag，开发者在PR被提交到开发环境前就修复了这个bug。

如果有别的人要设置这个工具和pipeline，请尽管让我分享。