Jenkins的Pipeline腳本在美團餐飲SaaS中的實踐

2019獨角獸企業重金招聘Python工程師標準>>>

一、背景

在日常開發中，我們經常會有發布需求，而且還會遇到各種環境，比如：線上環境（Online），模擬環境（Staging），開發環境（Dev）等。最簡單的就是手動構建、上傳服務器，但這種方式太過于繁瑣，使用持續集成可以完美地解決這個問題，推薦了解一下Jenkins。 Jenkins構建也有很多種方式，現在使用比較多的是自由風格的軟件項目（Jenkins構建的一種方式，會結合SCM和構建系統來構建你的項目，甚至可以構建軟件以外的系統）的方式。針對單個項目的簡單構建，這種方式已經足夠了，但是針對多個類似且又存在差異的項目，就難以滿足要求，否則就需要大量的job來支持，這就存在，一個小的變動，就需要修改很多個job的情況，難以維護。我們團隊之前就存在這樣的問題。

目前，我們團隊主要負責開發和維護多個Android項目，而且每個項目都需要構建，每個構建流程非常類似但又存在一定的差異。比如構建的流程大概如下：

克隆代碼；
靜態代碼檢查（可選）；
單元測試（可選）；
編譯打包APK或者熱補丁；
APK分析，獲取版本號（VersionCode），包的Hash值（apkhash）等；
加固；
上傳測試分發平臺；
存檔（可選）；
觸發自動化測試（可選）；
通知負責人構建結果等。

整個流程大體上是相同的，但是又存在一些差異。比如有的構建可以沒有單元測試，有的構建不用觸發自動化測試，而且構建結果通知的負責人也不同。如果使用自由風格軟件項目的普通構建，每個項目都要建立一個job來處理流程（可能會調用其他job）。

這種處理方式原本也是可以的，但是必須考慮到，可能會有新的流程接入（比如二次簽名），構建流程也可能存在Bug等多種問題。無論哪種情況，一旦修改主構建流程，每個項目的job都需要修改和測試，就必然會浪費大量的時間。針對這種情況，我們使用了Pipeline的構建方式來解決。

當然，如果有項目集成了React Native，還需要構建JsBundle。在Native修改以后，JsBundle不一定會有更新，如果是構建Native的時候一起構建JsBundle，就會造成很多資源浪費。并且直接把JsBundle這類大文件放在Native的Git倉庫里，也不是特別合適。

本文是分享一種Pipeline的使用經驗，來解決這類問題。

二、Pipeline的介紹

Pipeline也就是構建流水線，對于程序員來說，最好的解釋是：使用代碼來控制項目的構建、測試、部署等。使用它的好處有很多，包括但不限于：

使用Pipeline可以非常靈活的控制整個構建過程；
可以清楚的知道每個構建階段使用的時間，方便構建的優化；
構建出錯，使用stageView可以快速定位出錯的階段；
一個job可以搞定整個構建，方便管理和維護等。

Stage View

三、使用Pipeline構建

新建一個Pipeline項目，寫入Pipeline的構建腳本，就像下面這樣: 對于單個項目來說，使用這樣的Pipeline來構建能夠滿足絕大部分需求，但是這樣做也有很多缺陷，包括：

多個項目的Pipeline打包腳本不能公用，導致一個項目寫一份腳本，維護比較麻煩。一個變動，需要修改多個job的腳本；
多個人維護構建job的時候，可能會覆蓋彼此的代碼；
修改腳本失敗以后，無法回滾到上個版本；
無法進行構建腳本的版本管理，老版本發修復版本需要構建，可能和現在用的job版本已經不一樣了，等等。

四、把Pipeline當代碼寫

既然存在缺陷，我們就要找更好的方式，其實Jenkins提供了一個更優雅的管理Pipeline腳本的方式，在配置項目Pipeline的時候，選擇Pipeline script from SCM，就像下面這樣：這樣，Jenkins在啟動job的時候，首先會去倉庫里面拉取腳本，然后再運行這個腳本。在腳本里面，我們規定的構建方式和流程，就會按部就班地執行。構建的腳本，可以實現多人維護，還可以Review，避免出錯。以上就算搭建好了一個基礎，而針對多個項目時，還有一些事情要做，不可能完全一樣，以下是構建的結構圖：

如此以來，我們的構建數據來源分為三部分：job UI界面、倉庫的通用Pipeline腳本、項目下的特殊配置，我們分別來看一下：

job UI界面（參數化構建）

在配置job的時候，選擇參數化構建過程，傳入項目倉庫地址、分支、構建通知人等等。還可以增加更多的參數，這些參數的特點是，可能需要經常修改，比如靈活選擇構建的代碼分支。

項目配置

在項目工程里面，放入針對這個項目的配置，一般是一個項目固定，不經常修改的參數，比如項目名字，如下圖：

注入構建信息

QA提一個Bug，我們需要確定，這是哪次的構建，或者要知道commitId，從而方便進行定位。因此在構建時，可以把構建信息注入到APK之中。

把屬性注入到gradle.properties

# 應用的后端環境
APP_ENV=Beta
# CI 打包的編號，方便確定測試的版本，不通過 CI 打包，默認是 0
CI_BUILD_NUMBER=0
# CI 打包的時間，方便確定測試的版本，不通過 CI 打包，默認是 0
CI_BUILD_TIMESTAMP=0

在build.gradle里設置buildConfigField

#使用的是gradle.properties里面注入的值
buildConfigField "String", "APP_ENV", "\"${APP_ENV}\""
buildConfigField "String", "CI_BUILD_NUMBER", "\"${CI_BUILD_NUMBER}\""
buildConfigField "String", "CI_BUILD_TIMESTAMP", "\"${CI_BUILD_TIMESTAMP}\""
buildConfigField "String", "GIT_COMMIT_ID", "\"${getCommitId()}\""//獲取當前Git commitId
String getCommitId() {try {def commitId = 'git rev-parse HEAD'.execute().text.trim()return commitId;} catch (Exception e) {e.printStackTrace();}
}

顯示構建信息在App里，找個合適的位置，比如開發者選項里面，把剛才的信息顯示出來。QA提Bug時，要求他們把這個信息一起帶上

mCIIdtv.setText(String.format("CI 構建號:%s", BuildConfig.CI_BUILD_NUMBER));
mCITimetv.setText(String.format("CI 構建時間:%s", BuildConfig.CI_BUILD_TIMESTAMP));
mCommitIdtv.setText(String.format("Git CommitId:%s", BuildConfig.GIT_COMMIT_ID));

倉庫的通用Pipeline腳本

通用腳本是抽象出來的構建過程，遇到和項目有關的都需要定義成變量，再從變量里進行讀取，不要在通用腳本里寫死。


node {try{stage('檢出代碼'){//從git倉庫中檢出代碼git branch: "${BRANCH}",credentialsId: 'xxxxx-xxxx-xxxx-xxxx-xxxxxxx', url: "${REPO_URL}"loadProjectConfig();}stage('編譯'){//這里是構建，你可以調用job入參或者項目配置的參數，比如：echo "項目名字 ${APP_CHINESE_NAME}"//可以判斷if (Boolean.valueOf("${IS_USE_CODE_CHECK}")) {echo "需要靜態代碼檢查"} else {echo "不需要靜態代碼檢查"}}stage('存檔'){//這個演示的Android的項目，實際使用中，請根據自己的產物確定def apk = getShEchoResult ("find ./lineup/build/outputs/apk -name '*.apk'")def artifactsDir="artifacts"//存放產物的文件夾sh "mkdir ${artifactsDir}"sh "mv ${apk} ${artifactsDir}"archiveArtifacts "${artifactsDir}/*"}stage('通知負責人'){emailext body: "構建項目:${BUILD_URL}\r\n構建完成", subject: '構建結果通知【成功】', to: "${EMAIL}"}} catch (e) {emailext body: "構建項目:${BUILD_URL}\r\n構建失敗，\r\n錯誤消息：${e.toString()}", subject: '構建結果通知【失敗】', to: "${EMAIL}"} finally{// 清空工作空間cleanWs notFailBuild: true}}// 獲取 shell 命令輸出內容
def getShEchoResult(cmd) {def getShEchoResultCmd = "ECHO_RESULT=`${cmd}`\necho \${ECHO_RESULT}"return sh (script: getShEchoResultCmd,returnStdout: true).trim()
}//加載項目里面的配置文件
def loadProjectConfig(){def jenkinsConfigFile="./jenkins.groovy"if (fileExists("${jenkinsConfigFile}")) {load "${jenkinsConfigFile}"echo "找到打包參數文件${jenkinsConfigFile}，加載成功"} else {echo "${jenkinsConfigFile}不存在,請在項目${jenkinsConfigFile}里面配置打包參數"sh "exit 1"}
}

輕輕的點兩下Build with Parameters -> 開始構建，然后等幾分鐘的時間，就能夠收到郵件。

五、其他構建結構

以上，僅僅是針對我們當前遇到問題的一種不錯的解決方案，可能并不完全適用于所有場景，但是可以根據上面的結構進行調整，比如：

根據stage拆分出不同的Pipeline腳本，這樣方便CI的維護，一個或者幾個人維護構建中的一個stage；
把構建過程中的stage做成普通的自由風格的軟件項目的job，把它們作為基礎服務，在Pipeline中調用這些基礎服務等。

六、當遇上React Native

當項目引入了React Native以后，因為技術棧的原因，React Native的頁面是由前端團隊開發，但容器和原生組件是Android團隊維護，構建流程也發生了一些變化。

方案對比

方案	說明	缺點	優點
手動拷貝	等JsBundle構建好了，再手動把構建完成的產物，拷貝到Native工程里面	1. 每次手動操作，比較麻煩，效率低，容易出錯<br />2. 涉及到跨端合作，每次要去前端團隊主動拿JsBundle<br />3. Git不適合管理大文件和二進制文件	簡單粗暴
使用submodule保存構建好的JsBundle	直接把JsBundle放在Native倉庫的一個submodule里面，由前端團隊主動更新，每次更新Native的時候，直接就拿到了最新的JsBundle	1. 簡單無開發成本<br />2. 不方便單獨控制JsBundle的版本<br />3. Git不適合管理大文件和二進制文件	前端團隊可以主動更新JsBundle
使用submodule管理JsBundle的源碼	直接把JsBundle的源碼放在Native倉庫的一個submodule里面，由前端團隊開發更新，每次構建Native的時候，先構構建JsBundle	1. 不方便單獨控制JsBundle的版本<br />2. 即使JsBundle無更新，也需要構建，構建速度慢，浪費資源	方便靈活
分開構建，產物存檔	JsBundle和Native分開構建，構建完了的JsBundle分版本存檔，Native構建的時候，直接去下載構建好了的JsBundle版本	1. 通過配置管理JsBundle，解放Git<br />2. 方便Jenkins構建的時候，動態配置需要的JsBundle版本	1. 需要花費時間建立流程<br />2. 需要開發Gradle的JsBundle下載插件

前端團隊開發頁面，構建后生成JsBundle，Android團隊拿到前端構建的JsBundle，一起打包生成最終的產物。在我們開發過程中，JsBundle修改以后，不一定需要修改Native，Native構建的時候，也不一定每次都需要重新構建JsBundle。并且這兩個部分由兩個團隊負責，各自獨立發版，構建的時候也應該獨立構建，不應該融合到一起。

綜合對比，我們選擇了使用分開構建的方式來實現。

分開構建

因為需要分開發布版本，所以JsBundle的構建和Native的構建要分開，使用兩個不同的job來完成，這樣也方便兩個團隊自行操作，避免相互影響。 JsBundle的構建，也可以參考上文提到的Pipeline的構建方式來做，這里不再贅述。在獨立構建以后，怎么才能組合到一起呢？我們是這樣思考的：JsBundle構建以后，分版本的儲存在一個地方，供Native在構建時下載需要版本的JsBundle，大致的流程如下：

這個流程有兩個核心，一個是構建的JsBundle歸檔存儲，一個是在Native構建時去下載。

JsBundle歸檔存儲

方案	缺點	優點
直接存檔在Jenkins上面	1. JsBundle不能匯總瀏覽<br>2. Jenkins很多人可能要下載，命名帶有版本號，時間，分支等，命名不統一，不方便構建下載地址<br>3. 下載Jenkins上面的產物需要登陸授權，比較麻煩	1. 實現簡單，一句代碼就搞定，成本低
自己構建一個存儲服務	1. 工程大，開發成本高<br>2. 維護起來麻煩	可擴展，靈活性高
MSS<br>(美團存儲服務)	無	1. 儲存空間大<br>2. 可靠性高，配合CDN下載速度快<br>3. 維護成本低，價格便宜

這里我們選擇了MSS。上傳文件到MSS，可以使用s3cmd，但畢竟不是每個Slave上面都有安裝，通用性不強。為了保證穩定可靠，這里基于MSS的SDK寫個小工具即可，比較簡單，幾行代碼就可以搞定。

private static String TenantId = "mss_TenantId==";
private static AmazonS3 s3Client;public static void main(String[] args) throws IOException {if (args == null || args.length != 3) {System.out.println("請依次輸入：inputFile、bucketName、objectName");return;}s3Client = AmazonS3ClientProvider.CreateAmazonS3Conn();uploadObject(args[0], args[1], args[2]);
}public static void uploadObject(String inputFile, String bucketName, String objectName) {try {File file = new File(inputFile);if (!file.exists()) {System.out.println("文件不存在：" + file.getPath());return;}s3Client.putObject(new PutObjectRequest(bucketName, objectName, file));System.out.printf("上傳%s到MSS成功: %s/v1/%s/%s/%se", inputFile, AmazonS3ClientProvider.url, TenantId, bucketName, objectName);} catch (AmazonServiceException ase) {System.out.println("Caught an AmazonServiceException, which " +"means your request made it " +"to Amazon S3, but was rejected with an error response" +" for some reason.");System.out.println("Error Message:    " + ase.getMessage());System.out.println("HTTP Status Code: " + ase.getStatusCode());System.out.println("AWS Error Code:   " + ase.getErrorCode());System.out.println("Error Type:       " + ase.getErrorType());System.out.println("Request ID:       " + ase.getRequestId());} catch (AmazonClientException ace) {System.out.println("Caught an AmazonClientException, which " +"means the client encountered " +"an internal error while trying to " +"communicate with S3, " +"such as not being able to access the network.");System.out.println("Error Message: " + ace.getMessage());}
}

我們直接在Pipeline里構建完成后，調用這個工具就可以了。當然，JsBundle也分類型，在調試的時候可能隨時需要更新，這些JsBundle不需要永久保存，一段時間后就可以刪除了。在刪除時，可以參考MSS生命周期管理。所以，我們在構建JsBundle的job里，添加一個參數來區分。

//根據TYPE，上傳到不同的bucket里面
def bucket = "rn-bundle-prod"
if ("${TYPE}" == "dev") {bucket = "rn-bundle-dev" //有生命周期管理，一段時間后自動刪除
}
echo "開始JsBundle上傳到MSS"
//jar地址需要替換成你自己的
sh "curl -s -S -L  http://s3plus.sankuai.com/v1/mss_xxxxx==/rn-bundle-prod/rn.bundle.upload-0.0.1.jar -o upload.jar"
sh "java -jar upload.jar ${archiveZip} ${bucket} ${PROJECT}/${targetZip}"
echo "上傳JsBundle到MSS:${archiveZip}"

Native構建時JsBundle的下載

為了實現構建時能夠自動下載，我們寫了一個Gradle的插件。首先要在build.gradle里面配置插件依賴：

classpath 'com.zjiecode:rn-bundle-gradle-plugin:0.0.1'

在需要的Module應用插件：

apply plugin: 'mt-rn-bundle-download'

在build.gradle里面配置JsBundle的信息：

RNDownloadConfig {//遠程文件目錄,因為有多種類型，所以這里可以填多個。paths = ['http://msstest-corp.sankuai.com/v1/mss_xxxx==/rn-bundle-dev/xxx/','http://msstest-corp.sankuai.com/v1/mss_xxxx==/rn-bundle-prod/xxx/']version  = "1"//版本號，這里使用的是打包JsBundle的BUILD_NUMBERfileName = 'xxxx.android.bundle-%s.zip' //遠程文件的文件名,%s會用上面的version來填充outFile  = 'xxxx/src/main/assets/JsBundle/xxxx.android.bundle.zip' // 下載后的存儲路徑，相對于項目根目錄
}

插件會在package的task前面，插入一個下載的task，task讀取上面的配置信息，在打包階段檢查是否已經存在這個版本的JsBundle。如果不存在，就會去歸檔的JsBundle里，下載我們需要的JsBundle。當然，這里的version可以使用上文介紹的注入構建信息的方式，通過job參數的方式進行注入。這樣在Jenkins構建Native時，就可以動態地填寫需要JsBundle的版本了。這個Gradle插件，我們已經放到到了github倉庫，你可以基于此修改，當然，也歡迎PR。 https://github.com/zjiecode/rn-bundle-gradle-plugin