DevOps實(shí)踐系列文章，請參見連接。

概述

Gradle是CI過程工具，而不是系統(tǒng)。持續(xù)集成過程中的構(gòu)建、自動化測試、打包、發(fā)布都可以使用Gradle來完成。而持續(xù)進(jìn)程過程為我們降低各方面成本，提高產(chǎn)品信心，提高產(chǎn)品質(zhì)量有著非常重要的作用（不要問我為啥）。而我們很多研發(fā)人員非常討厭CI過程，這一點(diǎn)的問題原因是研發(fā)人員沒有從CI過程中獲取任何利益，而且還增加了維護(hù)成本。關(guān)于這一點(diǎn)等有機(jī)會的時(shí)候和大家討論一下《怎么統(tǒng)一研發(fā)，質(zhì)量，測試，管理之間的利益》（統(tǒng)一各方面的利益之后眾志成城，萬眾一心，我們的產(chǎn)品會更上一層樓)。

使用總結(jié)：

在使用Gradle過程中發(fā)現(xiàn)在Gradle中的很多特性，很多原理都很特別。這里說明幾個(gè)使用實(shí)踐。（這里不與makefile，maven，ant進(jìn)行對比）

• 關(guān)于Gradle的執(zhí)行的過程：

很多介紹Gradle的地方，都說Gradle腳本是一種配置腳本。他們說這句話的原因是因?yàn)樵贕radle中提供了很多插件，啟用插件后直接調(diào)用方法閉包進(jìn)行配置就可以完全完成項(xiàng)目需要的功能。所以，Gradle很多時(shí)候都是以配置文件的形式存在的。

但，Gradle的腳本不簡單是配置文件。從Gradle執(zhí)行的三個(gè)步驟可以看出：
1> Initialization：Gradle 支持單項(xiàng)目或者多項(xiàng)目構(gòu)建，在該階段，Gradle認(rèn)哪些項(xiàng)目會參與構(gòu)建，然后為每一個(gè)項(xiàng)目創(chuàng)建 Project 對象
2> Configuration：這個(gè)階段就是配置 Initialization 階段創(chuàng)建的 Project 對象，所有的配置腳本都會被執(zhí)行
3> Execution：這個(gè)階段 Gradle 會確認(rèn)哪些在 Configuration 階段創(chuàng)建和配置的 Task 會被執(zhí)行，哪些 Task會被執(zhí)行取決于gradle命令的參數(shù)以及當(dāng)前的目錄，確認(rèn)之后便會執(zhí)行

大家可以從Gradle執(zhí)行過程得出，Gradle的使用過程不止配置腳本那么簡單。具體可以看：
1> 在初始化階段，Gradle沒有指定默認(rèn)的初始化腳本，必須使用Gradle的命令行參數(shù)進(jìn)行指定。這個(gè)過程可以使用Gradle的Hook來完成相應(yīng)的回調(diào)注冊，以控制整個(gè)Gradle執(zhí)行過程。

參見：https://docs.gradle.org/current/userguide/init_scripts.html
https://docs.gradle.org/current/dsl/org.gradle.api.invocation.Gradle.html#org.gradle.api.invocation.Gradle:addListener(java.lang.Object)

2> 在配置階段，執(zhí)行的是相關(guān)的配置。比如說Project中的依賴管理閉包塊。屬性設(shè)置等都會直接執(zhí)行。但是這個(gè)階段不會執(zhí)行task內(nèi)部的action。所以，這個(gè)階段才叫做配置階段。

3> 在執(zhí)行階段，會執(zhí)行task的相關(guān)操作。在相對復(fù)雜的項(xiàng)目中很多時(shí)候需要在執(zhí)行階段對項(xiàng)目構(gòu)建進(jìn)行動態(tài)配置，在這個(gè)階段可以對項(xiàng)目中各種屬性在進(jìn)行配置。但是，動態(tài)配置過程必須在使用這些配置之前完成，要不也沒有任何用處。

所以，從上面可以得出，Gradle的執(zhí)行過程不像我們之前接觸過的CI工具那樣要不是純配置，要不是純動態(tài)。這一點(diǎn)是Gradle很大的特點(diǎn)。這種方式為我們很好的融合了配置 與 動態(tài)構(gòu)建過程，平衡了兩方的優(yōu)缺點(diǎn)。

• Gradle配置過程

在腳本執(zhí)行的時(shí)候，Gradle會配置一些特定類型的對象，這些對象就被稱為腳本的 delegate 對象，也是構(gòu)建領(lǐng)域的領(lǐng)域?qū)ο螅挛暮喎Q DO。
DO 的意義就在于腳本可以使用被代理的對象的方法——這一點(diǎn)非常重要，是腳本中可調(diào)用方法的重要來源。
參見：https://www.muzileecoding.com/gradlestudy/gradle-advaced-do.html

只要是被委托對象有的方法，都是可以直接調(diào)用的。而且還有一個(gè)比較復(fù)雜的方法查找過程，一層層的查找方法。所以，在查找在某一部分可以使用的方法是一個(gè)比較麻煩的過程。而在Gradle中的文檔又寫的很晦澀會導(dǎo)致學(xué)習(xí)成本提升，效率降低等問題。不過一般情況下直接查找DSL相關(guān)描述即可。

• Gradle腳本模塊化

模塊化過程分兩個(gè)大類：配置模塊化 和 過程模塊化。
配置模塊化是將Gradle的腳本分模塊的寫道不同的腳本下，來提高Gradle腳本的可讀性與可維護(hù)性。具體方法：

<pre>apply from: 'other.gradle'</pre>

使用apply來引入其他的腳本，但是，在真正使用過程中發(fā)現(xiàn)被引入的腳本的委托對象好像不像一般腳本那樣。不能直接使用Project一些特定的屬性或者task，只能在主腳本中通過不同的方式進(jìn)行調(diào)用。

過程模塊化是在被引入腳本中實(shí)現(xiàn)過程，方法，類等等，但是需要在主腳本里進(jìn)行調(diào)用。這種方法可以使用Gradle直接調(diào)用groovy腳本中的實(shí)現(xiàn)來完成，但是，沒有找到方法來使Gradle腳本調(diào)用groovy腳本。所以，這里的過程模塊化還是使用配置模塊化來進(jìn)行引入。不過使用特殊的方式進(jìn)行方法，類的導(dǎo)出。具體如下：

// Define methods as usual
def commonMethod1(param){ return true }
def commonMethod2(param){ return true } // Export methods by turning them into closures
ext{
commonMethod1 = this.&commonMethod1
otherNameForMethod2 = this.&commonMethod2
}

在被引入腳本中使用ext進(jìn)行導(dǎo)出，在主腳本中就可以正常使用了。

參見：http://stackoverflow.com/questions/18715137/extract-common-methods-from-gradle-build-script
https://docs.gradle.org/current/userguide/organizing_build_logic.html#sec:configuring_using_external_script

• 關(guān)于Groovy

在Gradle腳本中可以使用任意合法的Groovy語句。從Groovy的文檔可以了解到Groovy是一種可以在運(yùn)行期和編譯器進(jìn)行元編程的強(qiáng)大語言。元編程又是DSL的強(qiáng)大支撐。所以，Gradle才實(shí)現(xiàn)了這么強(qiáng)大的DSL，讓我們更容易理解Gradle。
參見：http://www.groovy-lang.org/metaprogramming.html

總結(jié)：

總結(jié)了一些Gradle的實(shí)踐，但是，這里最主要的核心內(nèi)容還是怎么提高程序的可理解性，可維護(hù)性，可測試性的內(nèi)容。提高這些更是為了降低成本。