背景描述

根據(jù)項(xiàng)目需求，現(xiàn)要在團(tuán)隊(duì)內(nèi)部搭建一個(gè)統(tǒng)一的打包平臺(tái)，實(shí)現(xiàn)對(duì)iOS和Android項(xiàng)目的打包。而且為了方便團(tuán)隊(duì)內(nèi)部的測(cè)試包分發(fā)，希望在打包完成后能生成一個(gè)二維碼，體驗(yàn)用戶(產(chǎn)品、運(yùn)營、測(cè)試等人員)通過手機(jī)掃描二維碼后就能直接安裝測(cè)試包。

該需求具有一定的普遍性，基本上所有開發(fā)APP的團(tuán)隊(duì)都可能會(huì)用到，因此我將整個(gè)需求實(shí)現(xiàn)的過程整理后形成此文，并且真正地做到了零基礎(chǔ)上手，到手即飛、開箱即用，希望能對(duì)大家有所幫助。

GitHub地址：https://github.com/debugtalk/JenkinsTemplateForApp

首先，先給大家展示下平臺(tái)建設(shè)完成后的整體效果： 

該平臺(tái)主要實(shí)現(xiàn)的功能有3點(diǎn)：

• 定期對(duì)GitHub倉庫進(jìn)行檢測(cè)，若有更新則自動(dòng)執(zhí)行構(gòu)建打包;
• 構(gòu)建成功后根據(jù)ipa/apk生成二維碼，并可在歷史構(gòu)建列表中展示各個(gè)版本的二維碼，通過手機(jī)掃描二維碼可直接安裝對(duì)應(yīng)版本;
• 在構(gòu)建結(jié)果頁面中展示當(dāng)次構(gòu)建的成果物(Artifact，如.ipa、.app、.apk、info.plist等文件)，供有需要的用戶進(jìn)行下載。

接下來，本文就開始對(duì)平臺(tái)建設(shè)的完整實(shí)現(xiàn)過程進(jìn)行詳細(xì)介紹。

安裝Jenkins

Jenkins依賴于Java運(yùn)行環(huán)境，因此需要首先安裝Java。

安裝Jenkins的方式有多種，可以運(yùn)行對(duì)應(yīng)系統(tǒng)類型的安裝包，可以通過docker獲取鏡像，也可以直接運(yùn)行war包。

我個(gè)人傾向于直接運(yùn)行war包的形式，只需下載jenkins.war后，運(yùn)行如下命令即可啟動(dòng)Jenkins。

$ nohup java -jar jenkins_located_path/jenkins.war --httpPort=88 & 

如果不指定httpPort，Jenkins的默認(rèn)端口為8080。

Jenkins插件

Jenkins有非常多的插件，可以實(shí)現(xiàn)各種功能的擴(kuò)展。

針對(duì)搭建的iOS/Android持續(xù)集成打包平臺(tái)，我使用到了如下幾個(gè)插件。

• GIT plugin
• SSH Credentials Plugin
• Git Changelog Plugin: 獲取倉庫提交的commit log
• build-name-setter：用于修改Build名稱
• description setter plugin：用于在修改Build描述信息，在描述信息中增加顯示QRCode(二維碼)
• Post-Build Script Plug-in：在編譯完成后通過執(zhí)行腳本實(shí)現(xiàn)一些額外功能
• Xcode integration: iOS專用(可選)
• Gradle plugin: Android專用(可選)

安裝方式也比較簡(jiǎn)單，直接在Jenkins的插件管理頁面搜索上述插件，點(diǎn)擊安裝即可。

創(chuàng)建項(xiàng)目(Job)

在Jenkins中，構(gòu)建項(xiàng)目以Job的形式存在，因此需要針對(duì)每個(gè)項(xiàng)目創(chuàng)建一個(gè)Job。有時(shí)候，一個(gè)項(xiàng)目中可能有多個(gè)分支同時(shí)在進(jìn)行開發(fā)，為了分別進(jìn)行構(gòu)建，也可以針對(duì)每個(gè)分支創(chuàng)建一個(gè)Job。

創(chuàng)建Job的方式有多種，本次只需要?jiǎng)?chuàng)建Freestyle project類型的即可。

Main page -> New Item -> Freestyle project 

對(duì)于一個(gè)持續(xù)集成打包平臺(tái)，每次打包都由4步組成：觸發(fā)構(gòu)建、拉取代碼、執(zhí)行構(gòu)建、構(gòu)建后處理。對(duì)應(yīng)的，在每個(gè)Job中也對(duì)應(yīng)了這幾項(xiàng)的配置。

配置Git代碼倉庫

要對(duì)項(xiàng)目進(jìn)行構(gòu)建，配置項(xiàng)目的代碼倉庫是必不可少的。由于當(dāng)前我們的項(xiàng)目托管在GitHub私有倉庫中，因此在此需要對(duì)Git進(jìn)行配置。

在【Source Code Management】配置欄目下，如果之前GIT plugin安裝成功，則會(huì)出現(xiàn)Git選項(xiàng)。

配置Git代碼倉庫時(shí)，有三項(xiàng)是必須配置的：倉庫URL地址(Repository URL)、倉庫權(quán)限校驗(yàn)方式(Credentials)，以及當(dāng)前Job需要構(gòu)建的代碼分支(Branches to build)。

在配置Repository URL時(shí)，選擇HTTPS URL或SSH URL均可。不過需要注意的是，Credentials要和Repository URL對(duì)應(yīng)，也就是說：

• 如果Repository URL是HTTPS URL形式的，那么Credentials就要采用GitHub用戶名密碼的校驗(yàn)方式;而且，如果在GitHub中開啟了2FA(two-factor authentication)，那么還需要在GitHub中創(chuàng)建一個(gè)Personal access token，輸入密碼時(shí)將這個(gè)Personal access token作為密碼進(jìn)行輸入。
• 如果Repository URL是SSH URL形式的，那么就需要先在Jenkins所在的服務(wù)器上創(chuàng)建一個(gè)SSH秘鑰對(duì)，并將公鑰添加到GitHub的SSH keys中，然后在填寫Credentials時(shí)，選擇SSH Username with private key的校驗(yàn)方式，填入GitHub Username、SSH私鑰、以及創(chuàng)建SSH秘鑰對(duì)時(shí)設(shè)置的Passphrase。

如果對(duì)Git權(quán)限校驗(yàn)的概念還比較模糊，可以參考《深入淺出Git權(quán)限校驗(yàn)》。

在配置Branches to build時(shí)，可以采用多種形式，包括分支名稱(branchName)、tagName、commitId等。其中分支名稱的形式用的最多，例如，若是構(gòu)建master分支，則填寫refs/heads/master，若是構(gòu)建develop分支，則填寫refs/heads/develop。

除了以上關(guān)于Git的必填配置項(xiàng)，有時(shí)根據(jù)項(xiàng)目的實(shí)際情況，可能還需要對(duì)Jenkins的默認(rèn)配置項(xiàng)進(jìn)行修改。

比較常見的一種情況就是對(duì)clone的配置進(jìn)行修改。

在Jenkins的默認(rèn)配置中，clone代碼時(shí)會(huì)拉取所有歷史版本的代碼，而且默認(rèn)的超時(shí)時(shí)限只有10分鐘。這就造成在某些項(xiàng)目中，由于代碼量本身就比較大，歷史版本也比較多，再加上網(wǎng)絡(luò)環(huán)境不是特別好，Jenkins根本沒法在10分鐘之內(nèi)拉取完所有代碼，超時(shí)后任務(wù)就會(huì)被自動(dòng)終止了(錯(cuò)誤狀態(tài)碼143)。

這種問題的解決方式也很簡(jiǎn)單，無非就是兩種思路，要么少拉取點(diǎn)代碼(不獲取歷史版本)，要么提高超時(shí)時(shí)限。對(duì)應(yīng)的配置在Advanced clone behaviours中：

• Shallow clone：勾選后不獲取歷史版本;
• Timeout (in minutes) for clone and fetch operation：配置后覆蓋默認(rèn)的超時(shí)時(shí)限。

配置構(gòu)建觸發(fā)器

代碼倉庫配置好了，意味著Jenkins具有了訪問GitHub代碼倉庫的權(quán)限，可以成功地拉取代碼。

那Jenkins什么時(shí)候執(zhí)行構(gòu)建呢?

這就需要配置構(gòu)建觸發(fā)策略，即構(gòu)建觸發(fā)器，配置項(xiàng)位于【Build Triggers】欄目。

觸發(fā)器支持多種類型，常用的有：

• 定期進(jìn)行構(gòu)建(Build periodically)
• 根據(jù)提交進(jìn)行構(gòu)建(Build when a change is pushed to GitHub)
• 定期檢測(cè)代碼更新，如有更新則進(jìn)行構(gòu)建(Poll SCM)

構(gòu)建觸發(fā)器的選擇為復(fù)合選項(xiàng)，若選擇多種類型，則任一類型滿足構(gòu)建條件時(shí)就會(huì)執(zhí)行構(gòu)建工作。如果所有類型都不選擇，則該Jenkins Job不執(zhí)行自動(dòng)構(gòu)建，但可通過手動(dòng)點(diǎn)擊【Build Now】觸發(fā)構(gòu)建。

關(guān)于定時(shí)器(Schedule)的格式，簡(jiǎn)述如下：

MINUTE HOUR DOM MONTH DOW

• MINUTE: Minutes within the hour (0-59)
• HOUR: The hour of the day (0-23)
• DOM: The day of the month (1-31)
• MONTH: The month (1-12)
• DOW: The day of the week (0-7) where 0 and 7 are Sunday.

通常情況下需要指定多個(gè)值，這時(shí)可以采用如下operator(優(yōu)先級(jí)從上到下)：

• *適配所有有效的值，若不指定某一項(xiàng)，則以*占位;
• M-N適配值域范圍，例如7-9代表7/8/9均滿足;
• M-N/X或*/X：以X作為間隔;
• A,B,C：枚舉多個(gè)值。

另外，為了避免多個(gè)任務(wù)在同一時(shí)刻同時(shí)觸發(fā)構(gòu)建，在指定時(shí)間段時(shí)可以配合使用H字符。添加H字符后，Jenkins會(huì)在指定時(shí)間段內(nèi)隨機(jī)選擇一個(gè)時(shí)間點(diǎn)作為起始時(shí)刻，然后加上設(shè)定的時(shí)間間隔，計(jì)算得到后續(xù)的時(shí)間點(diǎn)。直到下一個(gè)周期時(shí)，Jenkins又會(huì)重新隨機(jī)選擇一個(gè)時(shí)間點(diǎn)作為起始時(shí)刻，依次類推。

為了便于理解，列舉幾個(gè)示例：

• H/15 * * * *：代表每隔15分鐘，并且開始時(shí)間不確定，這個(gè)小時(shí)可能是:07,:22,:37,:52，下一個(gè)小時(shí)就可能是:03,:18,:33,:48;
• H(0-29)/10 * * * *：代表前半小時(shí)內(nèi)每隔10分鐘，并且開始時(shí)間不確定，這個(gè)小時(shí)可能是:04,:14,:24，下一個(gè)小時(shí)就可能是:09,:19,:29;
• H 23 * * 1-5：工作日每晚23:00至23:59之間的某一時(shí)刻;

配置構(gòu)建方式

觸發(fā)策略配置好之后，Jenkins就會(huì)按照設(shè)定的策略自動(dòng)執(zhí)行構(gòu)建。但如何執(zhí)行構(gòu)建操作，這還需要我們通過配置構(gòu)建方式來進(jìn)行設(shè)定。

常用的構(gòu)建方式是根據(jù)構(gòu)建對(duì)象的具體類型，安裝對(duì)應(yīng)的插件，然后采用相應(yīng)的構(gòu)建方式。例如，若是構(gòu)建Android應(yīng)用，安裝Gradle plugin之后，就可以選擇Invoke Gradle script，然后采用Gradle進(jìn)行構(gòu)建;若是構(gòu)建iOS應(yīng)用，安裝Xcode integration插件之后，就可以選擇Xcode，然后選擇Xcode進(jìn)行構(gòu)建。

該種方式的優(yōu)勢(shì)是操作簡(jiǎn)單，UI可視化，在場(chǎng)景不復(fù)雜的情況下可以快速滿足需求。不過缺點(diǎn)就是依賴于插件已有的功能，如果場(chǎng)景較復(fù)雜時(shí)可能單個(gè)插件還無法滿足需求，需要再安裝其它插件。而且，有些插件可能還存在一些問題，例如對(duì)某些操作系統(tǒng)版本或XCode版本兼容不佳，出現(xiàn)問題時(shí)我們就會(huì)比較被動(dòng)。

我個(gè)人更傾向于另外一種方式，就是自己編寫打包腳本，在腳本中自定義實(shí)現(xiàn)所有的構(gòu)建功能，然后在Execute Shell中執(zhí)行。這種方式的靈活度更高，各種場(chǎng)景的構(gòu)建需求都能滿足，出現(xiàn)問題后也能自行快速修復(fù)。

另外，對(duì)于iOS應(yīng)用的構(gòu)建，還有一個(gè)需要額外關(guān)注的點(diǎn)，就是開發(fā)者證書的配置。

如果是采用Xcode integration插件進(jìn)行構(gòu)建，配置會(huì)比較復(fù)雜，需要在Jenkins中導(dǎo)入開發(fā)證書，并填寫多個(gè)配置項(xiàng)。不過，如果是采用打包腳本進(jìn)行構(gòu)建的話，情況就會(huì)簡(jiǎn)單許多。只要在Jenkins所運(yùn)行的計(jì)算機(jī)中安裝好開發(fā)者證書，打包命令在Shell中能正常工作，那么在Jenkins中執(zhí)行打包腳本也不會(huì)有什么問題。

構(gòu)建后處理

完成構(gòu)建后，生成的編譯成果物(ipa/apk)會(huì)位于指定的目錄中。但是，如果要直接在手機(jī)中安裝ipa/apk文件還比較麻煩，不僅在分發(fā)測(cè)試包時(shí)需要將好幾十兆的安裝包進(jìn)行傳送，體驗(yàn)用戶在安裝時(shí)也還需要通過數(shù)據(jù)線將手機(jī)與計(jì)算機(jī)進(jìn)行連接，然后再使用PP助手或豌豆莢等工具進(jìn)行安裝。

當(dāng)前比較優(yōu)雅的一種方式是借助蒲公英(pgyer)或fir.im等平臺(tái)，將ipa/apk文件上傳至平臺(tái)后由平臺(tái)生成二維碼，然后只需要對(duì)二維碼鏈接進(jìn)行分發(fā)，體驗(yàn)用戶通過手機(jī)掃描二維碼后即可實(shí)現(xiàn)快速安裝，效率得到了極大的提升。

上傳安裝包文件，生成二維碼

不管是蒲公英還是fir.im，都有對(duì)應(yīng)的Jenkins插件，安裝插件后可以在Post-build中實(shí)現(xiàn)對(duì)安裝包的上傳。

除了使用Jenkins插件，fir.im還支持命令上傳的方式，蒲公英還支持HTTP Post接口上傳的方式。

我個(gè)人推薦采用命令或接口上傳的方法，并在構(gòu)建腳本中進(jìn)行調(diào)用。靈活是一方面，更大的好處是如果上傳失敗后還能進(jìn)行重試，這在網(wǎng)絡(luò)環(huán)境不是很穩(wěn)定的情況下極其必要。

Jenkins成功完成安裝包上傳后，pgyer/fir.im平臺(tái)會(huì)生成一個(gè)二維碼圖片，并在響應(yīng)中將圖片的URL鏈接地址進(jìn)行返回。

展示二維碼圖片

二維碼圖片的URL鏈接有了，那要怎樣才能將二維碼圖片展示在Jenkins項(xiàng)目的歷史構(gòu)建列表中呢?

這里需要用到另外一個(gè)插件，description setter plugin。安裝該插件后，在【Post-build Actions】欄目中會(huì)多出description setter功能，可以實(shí)現(xiàn)構(gòu)建完成后設(shè)置當(dāng)次build的描述信息。這個(gè)描述信息不僅會(huì)顯示在build頁面中，同時(shí)也會(huì)顯示在歷史構(gòu)建列表中。

有了這個(gè)前提，要將二維碼圖片展示在歷史構(gòu)建列表中貌似就可以實(shí)現(xiàn)了，能直觀想到的方式就是采用HTML的img標(biāo)簽，將<img url='qr_code_url'>寫入到build描述信息中。

這個(gè)方法的思路是正確的，不過這么做以后并不會(huì)實(shí)現(xiàn)我們預(yù)期的效果。

這是因?yàn)镴enkins出于安全的考慮，所有描述信息的Markup Formatter默認(rèn)都是采用Plain text模式，在這種模式下是不會(huì)對(duì)build描述信息中的HTML編碼進(jìn)行解析的。

要改變也很容易，Manage Jenkins -> Configure Global Security，將Markup Formatter的設(shè)置更改為Safe HTML即可。

更改配置后，我們就可以在build描述信息中采用HTML的img標(biāo)簽插入圖片了。

另外還需要補(bǔ)充一個(gè)點(diǎn)。如果是使用蒲公英(pyger)平臺(tái)，會(huì)發(fā)現(xiàn)每次上傳安裝包后返回的二維碼圖片是一個(gè)短鏈接，神奇的是這個(gè)短連接居然是固定的(對(duì)同一個(gè)賬號(hào)而言)。這個(gè)短連接總是指向最近生成的二維碼圖片，但是對(duì)于二維碼圖片的***URL地址，平臺(tái)并沒有在響應(yīng)中進(jìn)行返回。在這種情況下，我們每次構(gòu)建完成后保存二維碼圖片的URL鏈接就沒有意義了。

應(yīng)對(duì)的做法是，每次上傳完安裝包后，通過返回的二維碼圖片短鏈接將二維碼圖片下載并保存到本地，然后在build描述信息中引用該圖片的Jenkins地址即可。

收集編譯成果物(Artifacts)

每次完成構(gòu)建后，編譯生成的文件較多，但是并不是所有的文件都是我們需要的。

通常情況下，我們可能只需要其中的部分文件，例如.ipa/.app/.plist/.apk等，這時(shí)我們可以將這部分文件單獨(dú)收集起來，并在構(gòu)建頁面中展示出來，以便在需要時(shí)進(jìn)行下載。

要實(shí)現(xiàn)這樣一個(gè)功能，需要在【Post-build Actions】欄目中新增Archive the artifacts，然后在Files to archive中通過正則表達(dá)式指定成果物文件的路徑。

設(shè)置完畢后，每次構(gòu)建完成后，Jenkins會(huì)在Console Output中采用設(shè)定的正則表達(dá)式進(jìn)行搜索匹配，如果能成功匹配到文件，則會(huì)將文件收集起來。

總結(jié)

本文主要是對(duì)如何使用Jenkins搭建iOS/Android持續(xù)集成打包平臺(tái)的基礎(chǔ)概念和實(shí)施流程進(jìn)行了介紹。對(duì)于其中涉及到的執(zhí)行命令、構(gòu)建腳本(build.py)，以及Jenkins的詳細(xì)配置，出于篇幅長度和閱讀體驗(yàn)的考慮，并沒有在文中進(jìn)行詳細(xì)展開。

為了實(shí)現(xiàn)真正的開箱即用，我將Jenkins的配置文件和構(gòu)建腳本抽離出來形成一套模板，只需要導(dǎo)入到Jenkins中，然后針對(duì)具體的項(xiàng)目修改少量配置信息，即可將這一套持續(xù)集成打包平臺(tái)運(yùn)行起來，實(shí)現(xiàn)和文章開頭插圖中完全相同的功能效果。