Gradle for Android-建立持续集成

持续集成（Continuous integration：CI）是一个要求团队中的开发者定时地集成它们的工作的开发实践，经常每天多次集成。每次push到主仓库都要被一个自动化build验证。该实践尽可能的帮助检测问题，因此加速了开发和提升了代码质量。杰出的Martin Flowler写了一篇关于这个主题的文章，解释了这个概念和描述了最佳实践：
http://martinfowler.com/articles/continuousIntegration.html

我们将了解这些CI系统和学习如何使得Gradle对之起作用。本章最后，我们将提及一些使得CI更容易地Gradle技巧，不管已选的CI系统。

本章，我们将会学习以下主题：

• Jenkins
• TeamCity
• Travis CI
• Further automation

Jenkins

Jenkins在2005年被 Sun Microsystems公司最初发布为Hudson。时隔数年，它已变成Java社区里最流行的CI系统。在Sun Microsystems被Oracle收购后不久，Oracle和Java社区关于Hudson出现了冲突。当时无法解决，社区继续在Jenkins名下致力于该项目因为Hudson名称是被Oracle所有的。

Jenkins的强大与它的plugin系统紧密相关。每个在build系统中需要新功能的人都可以创建一个继承了Jenkins能力的新的plugin。这也是为什么为Android app或library建立一个自动化build是非常直接的。

建立Jenkins

如果还没有安装Jenkins并运行到构建机器上，从网站（https://jenkins-ci.org/）下载并遵循步骤。

开始安装Jenkins之前，需要确保拥有了构建Android app或library需要的所有的库。为了在Java中构建所有事物，需要首先下载并安装JDK，可从Java网站
（http://www.oracle.com/technetwork/java/javase/downloads/index.html）下载。

也要确保安装了Android SDK和build工具。不需要在build服务器上安装IDE，除非想要在build机器上打开项目。如果仅想下载SDK工具，可从Android开发者网站
（https://developer.android.com/sdk/index.html#Other）下载。一旦下载并安装，需要能够在SDK目录运行Android命令，以便能够安装需要的API和build工具。

一旦Java和Android SDK都已安装，需要在Jenkins中配置。在build服务器上打开web浏览器并导向到Jenkins主页。转到Manage Jenkins | Configure System并回滚到Global Properties。添加两个环境变量，ANDROID_HOME和JAVA_HOME,并把它们的值设为正确的目录，如下截图：

也需要安装Gradle plugin。转到Manage Jenkins | Manage Plugin，导向到Available标签，并搜索Gradle。当找到Gradle plugin的位置，简单地检测箱子和点击Download now and install after restart。 该plugin会使得它能够构建牵扯到Gradle的步骤。

配置build

一旦安装了所需的全部事物后，可以在Jenkins中创建一个CI项目。首先要做的就是建立VCS仓库，以便Jenkins知道从哪里获取项目源码。基于仓库活动，使用build触发器或选择手动操作，可以建立Jenkins自动地构建app或library。为了实现实际的build，需要添加一个调用了Gradle脚本的build步骤。可以配置Jenkins使用Gradle Wrapper，后者在Android项目中默认生成。使用Gradle Wrapper不仅避免了在build服务器上手动安装Gradle，也确保了Gradle的所有更新都是被自动处理的。检查Make gradlew executable是个不错的注意。这也解决了用于执行Gradle Wrapper的权限问题，当想把在Windows设备上被创建的时候。

对于build步骤，可以输入一个友好的描述，并可选择性地添加两个开关info和stacktrace。info开关用于打印build进程更多的信息，在出错的情况下很有用。如果build导致了异常，stacktrace开关会打印该异常的堆栈信息。有时可能需要更详细的信息，这种情况在可以使用full-stacktrace开关代替。

为了完成配置，指定想要执行的gradle task。首先，执行clean task，确保当前build没有输出遗漏。其次，执行build task，它会触发所有变量的build。Jenkins配置如下：

保存了项目配置后，可以运行该build。build成功结束后，为所有的build变体创建了APK。可以使用特定的gradle task描述这些APK。本章末尾我们会提及自动化描述，因为它不是针对于任何build系统的。

TeamCity

不像Jenkins，TeamCity是仅对开源项目免费的专利产品。由JetBrains创建和管理。这与创建了IntelliJ IDEA的公司是同一家，TeamCity支持使用Gradle支持Android build。

建立TeamCity

如果还没安装TeamCity，从JetBrains网站
（https://www.jetbrains.com/teamcity/）下载并遵守步骤。

为了开始使用TeamCity构建Android app和library，需要确保JDK、Android SDK和Android build工具都在build server上安装了。可以发现关于此的说明在Jenkins节。也需要添加ANDROID_HOME到机器的环境变量中并指出Android SDK目录。

不像Jenkins，TeamCity不要求任何plugin触发Gradle build，因为Teamcity已经内嵌支持运行gradle。

配置build

为了建立Android build，通过创建一个新项目开始。你所需要做的就是提供名称。一旦项目被创建，就可以开始配置它了。首先，需要添加一个VCS源以便TeamCity能够找到项目源码。然后需要创建一个新的build配置。也需要把VCS关联到build配置中。万事俱备后，可以添加一个新的build步骤，如果摁Auto-detect build steps按钮，TeamCity将会基于项目内容，尝试确定必须的build步骤。假设一个基于Gradle的Android项目，如下：

TeamCity检测到项目使用Gradle而且存在Gradle Wrapper。可以仅选择Gradle build步骤，并添加到build配置中。如果不需要提前做任何事，这就足够确保你的Android app能够被build了。可以通过打开项目概览并点击Run…按钮测试配置。

Travis CI

如果项目的仓库是托管在GitHub上，可以使用Travis CI自动化构建。Travis CI(https://travis-ci.org/)是个开源的持续集成系统，并对公共存储库免费使用。对于私有存储库有个付费方案，但是本书中我们将仅了解免费的版本。

当一个新的commit被push到仓库时，Travis检测并自动地启动build。默认情况下，Travis 构建所有分支，而非仅master分支。也自动地构建所有的pull请求；对于开源项目来说是个有用的特性。

因为Travis如何工作是内部地，不能配置build server自身。代之，需要创建一个包含了Travis需要构建app或library的所有信息的配置文件。

配置build

如果想要Travis构建项目，首先需要注册Travis CI并把账号连接到GitHub。一旦这么做了，需要在settings中enable你的项目。

为了配置build进程，Travis要求你创建一个包含了整个安装的叫做.travis.yml的文件。为了配置Android项目，需要定义语言并添加一些Android特定属性：

language: androidandroid:    components:        # The build tools version used by your project        - build-tools-22.0.1        # The SDK version used to compile your project        - android-22        # Additional components        - extra-android-m2repository

语言设置指明了要运行哪build进程。这种情况下，你要构建一个Android app。Android特定属性包括需要使用的build工具版本和Android SDK版本。Travis将下载这些在运行build task之前。如果利用支持库或Google Play Services，需要明确指明因为Travis也需要从这些依赖中下载仓库。

如果在Windows上创建一个Android项目，Gradle Wrapper文件会有权限问题。因此，在运行时间的build脚本之前修复权限是个好主意。可以添加一个预构建步骤如下：

before_script:    # Change Gradle wrapper permissions    - chmod +x gradlew

为了启动build自身，添加以下代码到Travis配置文件中：

# Let's buildscript: ./gradlew clean build

该命令将运行Gradle Wrapper，就像你在机器上执行clean和build task一样。

配置完Travis build后，可以commit并push文件到项目的GitHub仓库。如果所有事情都是正确建立，Travis将启动build进程。项目成功构建时如下所观：

每次build后Travis也会发邮件报告。如果你是一个定期会被pull的开源项目维护者这将格外有用。Travis邮件如下：

你会很快注意到Travis有个很大的副作用，就是速度。对于每个你触发的build，Travis不会给任何特定的机器，而是启动了一个虚拟机。这意味着每个新的build，在构建app或library之前，Travis都要下载并安装Android SDK和build工具。

优势方面，Travis是免费和公开的，使得对于开源项目来说简直是完美。Travis也自动地构建pull请求，这使得你放心当有人提交一个分支到你的代码时。

Further automation

大部分现代的持续集成系统都支持Gradle，默认或通过一个plugin。这意味着较之仅构建app或library，可以创建各种Gradle task进一步自动化build。使用Gradle task定义额外的build步骤较之CI系统自身就是额外的build步骤来说，是更方便的。很容易在你的开发机器上运行一个自定义的Gradle task。一个自定义的Jenkins build步骤，另一方面，是不可能的没有安装Jenkins的话。在确定的CI系统中有额外的步骤也使得它更难切换到不同的CI系统中。Gradle task也能容易的导入到其他项目中。本节，我们将了解使用Gradle task和plugin，进一步自动化build和部署app及library的几种方式。

SDK管理者插件

有时你可能遇到的文件就是build server上的Android SDK不是最新的。当为app或library更新SDK版本时，也需要在build server上安装新的SDK。如果有多个build代理，就会很麻烦。

感谢社区的努力，有个用来检测是否build依赖于一个不存在的Android SDK版本的Gradle 插件。如果SDK不存在，plugin将自动下载。

SDK管理者插件将不仅下载buld配置文件中指定的编译SDK，也会下载build和platform tools的正确版本。如果项目依赖于支持库或Google Play Service，插件也将下载这些的指定版本。

SDK管理者插件是个开源插件，可以发现在GitHub
（https://github.com/JakeWharton/sdk-manager-plugin）找到源码。

运行测试

如果想在build进程期间在build server上运行单元测试（JUnit或Robolectric），需要简单地添加相应的task到Gradle executiong中。如果想运行任意功能测试，将需要模拟器安装app，所以可以使用gradlew connectedAndroidTest运行测试。运行模拟器的最简单的选项就是在build server上导入一个模拟器，并一直保持打开。不幸的是，没有选项解决方案，因为Android模拟器是非常容易崩溃，尤其当连续打开多天时。

如果使用Jenkins，有个插件叫做Android Emulator Plugin（https://wiki.jenkins-ci.org/display/JENKINS/Android+Emulator+Plugin）可以被配置为app或library的每次build导入模拟器。TeamCity也有个丰富的插件生态系统，并且有个叫做Android Emulator的插件可以以如Jenkins插件相同的方式建立模拟器。可以在官方TeamCity插件主页找到它（https://confluence.jetbrains.com/display/TW/TeamCity+Plugins）

Travis CI能够启动模拟器，但这是一个实验性的功能。如果无论如何要尝试一下，在Travis build期间添加如下片段到.travis.yml配置文件去导入一个Android模拟器：

# Emulator Management: Create, Start and Waitbefore_script:    - echo no | android create avd --force -n test -t android-22 --abi armeabi-v7a    - emulator -avd test -no-skin -no-audio -no-window &    - android-wait-for-emulator    - adb shell input keyevent 82 &

android-wait-for-emulator命令告诉Travis等待模拟器启动。当模拟器启动后，执行adb shell input keyevent 82 &解锁屏幕。之后，可以告知Gradle运行测试。

持续化部署

为了帮助开发者自动化部署Android app，Google发布了Google Play Developer API，用于以程序的方式把APK推送到Google Play（https://developers.google.com/android-publisher）。该API减去了打开浏览器、注册Google Play和使用web接口上传APK的需求。较之基于Google Play Developer API创建自己的发布脚本，在成功构建后，可直接从build系统使用一个插件直接推送APK到Google Play。有个Jenkins插件叫做Google Play Android Publisher
(https://wiki.jenkins-ci.org/display/JENKINS/Google+Play+Android+Publisher+Plugin这里写链接内容)可以为你处理这个。一个更好的选择，但是要使用Gradle task，以便可以从任何设备和任何种类的持续集成系统中执行发布task。Android社区的一些人围绕Google Play Developer API创建了一个Gradle插件，可以使你配置整个发布过程。可以在GitHub（https://github.com/Triple-T/gradle-play-publisher）找到Gradle Play Publisher Gradle插件源码。也可以通过Maven Central或JCenter获得。

为了使用这个插件，添加以下代码到主build.gradle文件中：

buildscript {    repositories {        jcenter()    }    dependencies {        classpath 'com.github.triplet.gradle:play-publisher:1.0.4'    }}

然后在模块的build.gradle文件中应用该插件：

apply plugin: 'play'

当应用Gradle Play Publisher插件到build中时，要有一些新的task：

• publishApkRelease ：上传APK和最近的改变
• publisListingRelease：上传描述和图片
• publishRelease：上传所有

如果有不同的build变体，也可以执行一个这些task的一个特定变体版本，例如，publishApkFreeRelease和publishApkPaidRelease。

为了访问到Google Play Developer API，需要建立一个服务账号。该操作不在本书范围之内，但是是被要求的如果你想使用Gradle Play Publisher插件的话。为了开始，遵循以下文档中的步骤（https://developers.google.com/android-publisher/getting_started）。

一旦创建了服务账号后，可以在build配置文件中输入证书，如下：

play {    serviceAccountEmail = 'serviceaccount'    pk12File = file('key.p12')}

play块是指定用于Gradle Play Publisher插件的属性。除了服务账号证书外，也可以指定APK应该被推送的路径：

play {    track = 'production'}

默认的路径是alpha，但是可以改成beta或production。

beta发布

Android app的beta测试有很多选择，例如Google Play store自身的beta路径。另一个选择就是Crashlytics（https://crashlytics.com/），非常好的集成了Gradle。Crahslytics小组创建了一个自定义插件，它不仅仅创建新的Gradle task发布build到它们的平台上，也勾入Android插件的task去处理ProGuard映射。

为了开始Crashlytics，遵循它们官网的步骤。一定能安装后，将开始勾入你的build。Crashlytic插件暴露了一个叫做crashlyticsUploadDestributionInternal的新的task，可用于上传APK到Crashlytics。为了推送一个新的app版本，首先需要使用build或assemble task构建它。一旦APK准备好了，可以使用crashUploadDistributionInternal task上传到Crashlytics。这个Crashlytics插件为项目中的每个build变体创建了一个上传task。

感谢自定义Gradle插件，对于开发者使用Crashlytic非常容易。也使得轻而易举的上传测试build到Crashlytics，因为仅需要执行一个额外的task在build进程中。这是一个非常好的例子关于合适地使用Gradle会有多么强大，以及一个好的Gradle插件如何使得开发者的生活更加容易。

总结

本章节中，我们介绍了一下流行的持续集成系统，并解释了我们如何使用它们去自动化构建Android app和library。你学习到如何配置CI系统使用Gradle构建Android项目。然后我们了解到好几种Gradle插件帮助我们进一步自动化构建和部署进程，并解释了如何在build server自动地运行测试。

在一章节，我们将会学习gradle更高级的特性和基于Gradle构建的优化。我们也将看到通过直接从Gradle中使用Ant task移植一个大的Ant build配置，并使用很少的步骤把它们导入到build中。