【DevOps】Android App工程的QA自动化实践
推荐超级课程：
在我们的项目，我们过去5年一直在编写应用代码库（20万行代码），但每当新的PR或提交合并到代码库时，我们没有进行任何验证，您只需要从其他同行那里手动获取审查。有时这会导致无法编译的代码，单元测试失败，应用启动时崩溃，内存泄漏。
这次在我们的BBD之后，我们决定在提出新的PR时进行一些自动验证，以确保只有在以下验证成功后，PR才能被合并：
代码编译 -:确保代码能够使用error-prone（https://github.com/google/error-prone ）编译，并生成发布构建。
Checkstyle验证 -: https://github.com/checkstyle/checkstyle 确保开发者在提出PR时遵循正确的编码标准，您也可以创建自己的自定义checkstyle xml文件并包含您想要添加的验证。
FindBugs验证 -: http://findbugs.sourceforge.net/ 曾经我们的代码库中有大约1600个FindBugs警告，我们修复了所有高优先级的警告，并确保新的提交不会添加任何高优先级的警告。您可以设置在构建过程中因为任何警告而失败，但目前我们只针对高优先级警告失败。您可以在build.gradle文件中设置警告级别。
单元测试验证 -: 在合并PR之前确保所有单元测试都成功通过。
Apk大小验证 -: 应用大小始终是从应用商店下载应用的关键因素，在每次新版本发布时，我们必须确保我们没有添加任何会大幅增加应用大小的功能。
以前我们通常在发布前2-3天评估应用大小，在这种情况下，很难找出导致apk大小增加的提交，考虑到我们有30天的发布周期，并且有10个开发者定期在该分支上提交。
我们是如何解决这个问题的 -:
感谢apk大小分析器工具 https://wiki.jenkins.io/display/JENKINS/Android+Apk+Size+Watcher+Plugin ，我们能够跟踪每次新提交的Apk大小，并且如果与之前的构建相比，应用大小超过了特定的阈值增加，它还会使PR无法合并。
所有这些验证将需要大约8分钟来完成，这将确保
- 无法编译的代码永远不会被提交到分支。
- 现有的单元测试不会失败。
- 轻松找出增加了应用大小的提交。
- 确保新的提交遵循编码标准，并且不包含任何Java错误。
失败的PR只有在管理员批准后才能合并 -:
除此之外，我们还会在日常基础上使用付费工具进行一些其他检查，这些检查将构建发布分支的apk并进行以下验证：
内存泄漏，应用崩溃，应用减速 - 除了应用大小，我们还监控内存泄漏，应用冷启动时间和应用崩溃。为了确保新的更改不会影响这些值，我们集成了NimbleDroid工具（https://nimbledroid.com/ ，付费版），它将使我们能够每天验证所有这些更改。
