从持续集成到部署

　　Jenkins最基本的持续集成

　　在做好了各种测试实践后，需要考虑如何保证这种实践在每一次提交都产生效果，并且提供对代码库的不断保护。这里引入常用敏捷实践中持续集成的概念。

　　持 续集成主要是为了能够更好为产品在整个开发过程中提供交付保障。相对比传统服务器领域，移动开发中，碰到最多的问题是环境的不同与测试包的相对封闭。以前 通过改一个配置实现服务器实时测试修改的方法，很难直接应用于移动开发。此外，作为整个服务边缘的移动应用，往往会遇到大量不同的测试环境。

　　所以如图6所描述的，需要在持续集成服务器上部署相关的应用包，完成对不同环境的开发与测试。这样的测试通常是由持续集成服务器引导的不同物理移动设备来完成，以保证最终测试包的可交付性。尤其适用于对于网络和性能等相关的测试。

图6 利用相关应用包完成对不同环境的开发与测试

　　当然，如果细心的话，也可以看出图6中对于产品版本与配置管理的一些端倪。

　　OTA自动化部署

　　持续集成帮助我们有了稳定的应用包。有了这些包，我们现在就差最后的一步—自动化部署。在移动的真实交付中，由于安装包需要下载到移动终端完成。所以自动化部署也必须要模拟这一过程完成交付。

　　这里我们推荐使用持续集成服务器关于邮件服务推送的应用插件来完成。具体的过程通常为，在完成编译并顺利通过测试后，持续集成服务器会根据制定终端列表，推送测试内容以供安装。推送者收到请求后，可以根据需要自行安装相应apk文件，达到部署效果。

　　这样做打通了移动开发最后一步的障碍。并有效沟通了管理、设计、业务与测试的各个部门人员。持续集成管理员还可以通过管理安装邮件列表的形式，自行选择不同版本，环境安装包对不同相关人员的推送。

　　让调试可持续化

　　有了开发，有了一系列持续化集成作业，有了作业完成的自动化打包部署，貌似可以休息了。但正如DevOps概念所说，虽然做了许多努力，但我们依然承认会有 错误的出现，那么如何尽早发现错误并准确定位，最终完成就显得尤为重要。在不同阶段，我们尝试使用不同的方法来进行调试。下面介绍我们的两个实践方法。

　　开发后调试。旧有的logcat是一个很好的调试工具，它在开发中起到了重要的作用，但对于做探索测试的QA们而言，大量繁琐的Debug信息往往令人看得眼花缭乱。

　　这 时我们就需要一个更好的工具进行错误栈的准确定位，因此我们引入了Acra。这是一个开源工具包，其功能是自动化地将Android应用的错误报告发送到 GoogleDoc或着Email等的可记录文本中。它的目的是为了帮助Android应用开发者在错误发生时收集行为和技术数据。