移动App发布后，质量成本高？看Esty如何应对发布质量
Esty工程团队一直秉承“持续交付”这一工作理念，其每天在web端部署超过50次。但移动应用的审核周期、用户升级惰性都令成本大大提升。如何在移动端提高发布质量呢？Esty的做法是这样的......
每次提交(git push)都要在主干上，并在集成服务器上编译
app集成的所需环境准备工序自动化
对于我们构建和运行测试所需安装的Xcode，Git，以及所有Android包来说，其中95%的工作，我们已经通过编程方式实现安装了，还有一些步骤需要手工完成。
每次提交都要做构建，并可以每日“吃自己狗食”
通过IRC或邮件，开发人员会得到构建结果的通知，这样，每多小问题在被发现几分钟内就会得到解决。除了push后立即构建app，我们还提供每日构建包，任何一个Etsy员工都可以把这个每日构建包安装到他们的移动设备上——这是“吃自己狗食”的精髓。促进我们的同事安装预发布版本的简单方法就是在他们使用官方发布版本时提醒（骚扰）他们。
每次提交就自动运行测试
聚焦于一些功能性测试，当然前提是所用的API已经在Web端被测试过了（通过单元测试和冒烟测试）。这不但可以尽早发现了bug，而且还能发现移动应用的一部分崩溃。测试同时运行在多个不同的系统及设备的组合上。
在物理设备上运行我们的测试
利用供应商Appthwack的设备云，我们每次提交代码都会在一组专门的设备上运行测试，同时，每天晚上在更大范围的设备上运行每日回归测试。
一定要有一个dashboard
我们有15个Jenkins jobs来构建和运行测试，快速地把关键信息通知到所有开发人员，还不产生信息噪音是一个巨大的挑战。一个自己开发的dashboard来展示所有的配置和测试状态不是一个不错的选择。
代码静态分析与code reviews
自动化测试不能发现所有的bug和潜在的崩溃——这与web端一样，开发人员在提交到主干前强制进行code reviews和自动代码静态分析。
这是持续集成的第一基本原则，也是问题一旦被引入，能够快速发现的第一关：编译失败。在IDE里构建并不算持续集成哟～