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: android
android:
    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 build
script: ./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 Wait
before_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中。