Jenkins的Pipeline脚本在美团餐饮SaaS中的实践
2019獨(dú)角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>
一、背景
在日常開發(fā)中，我們經(jīng)常會(huì)有發(fā)布需求，而且還會(huì)遇到各種環(huán)境，比如：線上環(huán)境（Online），模擬環(huán)境（Staging），開發(fā)環(huán)境（Dev）等。最簡(jiǎn)單的就是手動(dòng)構(gòu)建、上傳服務(wù)器，但這種方式太過于繁瑣，使用持續(xù)集成可以完美地解決這個(gè)問題，推薦了解一下Jenkins。 Jenkins構(gòu)建也有很多種方式，現(xiàn)在使用比較多的是自由風(fēng)格的軟件項(xiàng)目（Jenkins構(gòu)建的一種方式，會(huì)結(jié)合SCM和構(gòu)建系統(tǒng)來構(gòu)建你的項(xiàng)目，甚至可以構(gòu)建軟件以外的系統(tǒng)）的方式。針對(duì)單個(gè)項(xiàng)目的簡(jiǎn)單構(gòu)建，這種方式已經(jīng)足夠了，但是針對(duì)多個(gè)類似且又存在差異的項(xiàng)目，就難以滿足要求，否則就需要大量的job來支持，這就存在，一個(gè)小的變動(dòng)，就需要修改很多個(gè)job的情況，難以維護(hù)。我們團(tuán)隊(duì)之前就存在這樣的問題。
目前，我們團(tuán)隊(duì)主要負(fù)責(zé)開發(fā)和維護(hù)多個(gè)Android項(xiàng)目，而且每個(gè)項(xiàng)目都需要構(gòu)建，每個(gè)構(gòu)建流程非常類似但又存在一定的差異。比如構(gòu)建的流程大概如下：
- 克隆代碼；
- 靜態(tài)代碼檢查（可選）；
- 單元測(cè)試（可選）；
- 編譯打包APK或者熱補(bǔ)丁；
- APK分析，獲取版本號(hào)（VersionCode），包的Hash值（apkhash）等；
- 加固；
- 上傳測(cè)試分發(fā)平臺(tái)；
- 存檔（可選）；
- 觸發(fā)自動(dòng)化測(cè)試（可選）；
- 通知負(fù)責(zé)人構(gòu)建結(jié)果等。
整個(gè)流程大體上是相同的，但是又存在一些差異。比如有的構(gòu)建可以沒有單元測(cè)試，有的構(gòu)建不用觸發(fā)自動(dòng)化測(cè)試，而且構(gòu)建結(jié)果通知的負(fù)責(zé)人也不同。如果使用自由風(fēng)格軟件項(xiàng)目的普通構(gòu)建，每個(gè)項(xiàng)目都要建立一個(gè)job來處理流程（可能會(huì)調(diào)用其他job）。
這種處理方式原本也是可以的，但是必須考慮到，可能會(huì)有新的流程接入（比如二次簽名），構(gòu)建流程也可能存在Bug等多種問題。無論哪種情況，一旦修改主構(gòu)建流程，每個(gè)項(xiàng)目的job都需要修改和測(cè)試，就必然會(huì)浪費(fèi)大量的時(shí)間。針對(duì)這種情況，我們使用了Pipeline的構(gòu)建方式來解決。
當(dāng)然，如果有項(xiàng)目集成了React Native，還需要構(gòu)建JsBundle。在Native修改以后，JsBundle不一定會(huì)有更新，如果是構(gòu)建Native的時(shí)候一起構(gòu)建JsBundle，就會(huì)造成很多資源浪費(fèi)。并且直接把JsBundle這類大文件放在Native的Git倉(cāng)庫(kù)里，也不是特別合適。
本文是分享一種Pipeline的使用經(jīng)驗(yàn)，來解決這類問題。
二、Pipeline的介紹
Pipeline也就是構(gòu)建流水線，對(duì)于程序員來說，最好的解釋是：使用代碼來控制項(xiàng)目的構(gòu)建、測(cè)試、部署等。使用它的好處有很多，包括但不限于：
- 使用Pipeline可以非常靈活的控制整個(gè)構(gòu)建過程；
- 可以清楚的知道每個(gè)構(gòu)建階段使用的時(shí)間，方便構(gòu)建的優(yōu)化；
- 構(gòu)建出錯(cuò)，使用stageView可以快速定位出錯(cuò)的階段；
- 一個(gè)job可以搞定整個(gè)構(gòu)建，方便管理和維護(hù)等。
Stage View
三、使用Pipeline構(gòu)建
新建一個(gè)Pipeline項(xiàng)目，寫入Pipeline的構(gòu)建腳本，就像下面這樣: 對(duì)于單個(gè)項(xiàng)目來說，使用這樣的Pipeline來構(gòu)建能夠滿足絕大部分需求，但是這樣做也有很多缺陷，包括：
- 多個(gè)項(xiàng)目的Pipeline打包腳本不能公用，導(dǎo)致一個(gè)項(xiàng)目寫一份腳本，維護(hù)比較麻煩。一個(gè)變動(dòng)，需要修改多個(gè)job的腳本；
- 多個(gè)人維護(hù)構(gòu)建job的時(shí)候，可能會(huì)覆蓋彼此的代碼；
- 修改腳本失敗以后，無法回滾到上個(gè)版本；
- 無法進(jìn)行構(gòu)建腳本的版本管理，老版本發(fā)修復(fù)版本需要構(gòu)建，可能和現(xiàn)在用的job版本已經(jīng)不一樣了，等等。
四、把Pipeline當(dāng)代碼寫
既然存在缺陷，我們就要找更好的方式，其實(shí)Jenkins提供了一個(gè)更優(yōu)雅的管理Pipeline腳本的方式，在配置項(xiàng)目Pipeline的時(shí)候，選擇Pipeline script from SCM，就像下面這樣： 這樣，Jenkins在啟動(dòng)job的時(shí)候，首先會(huì)去倉(cāng)庫(kù)里面拉取腳本，然后再運(yùn)行這個(gè)腳本。在腳本里面，我們規(guī)定的構(gòu)建方式和流程，就會(huì)按部就班地執(zhí)行。構(gòu)建的腳本，可以實(shí)現(xiàn)多人維護(hù)，還可以Review，避免出錯(cuò)。 以上就算搭建好了一個(gè)基礎(chǔ)，而針對(duì)多個(gè)項(xiàng)目時(shí)，還有一些事情要做，不可能完全一樣，以下是構(gòu)建的結(jié)構(gòu)圖：
如此以來，我們的構(gòu)建數(shù)據(jù)來源分為三部分：job UI界面、倉(cāng)庫(kù)的通用Pipeline腳本、項(xiàng)目下的特殊配置，我們分別來看一下：
job UI界面（參數(shù)化構(gòu)建）
在配置job的時(shí)候，選擇參數(shù)化構(gòu)建過程，傳入項(xiàng)目倉(cāng)庫(kù)地址、分支、構(gòu)建通知人等等。還可以增加更多的參數(shù) ，這些參數(shù)的特點(diǎn)是，可能需要經(jīng)常修改，比如靈活選擇構(gòu)建的代碼分支。
項(xiàng)目配置
在項(xiàng)目工程里面，放入針對(duì)這個(gè)項(xiàng)目的配置，一般是一個(gè)項(xiàng)目固定，不經(jīng)常修改的參數(shù)，比如項(xiàng)目名字，如下圖：
注入構(gòu)建信息
QA提一個(gè)Bug，我們需要確定，這是哪次的構(gòu)建，或者要知道commitId，從而方便進(jìn)行定位。因此在構(gòu)建時(shí)，可以把構(gòu)建信息注入到APK之中。
倉(cāng)庫(kù)的通用Pipeline腳本
通用腳本是抽象出來的構(gòu)建過程，遇到和項(xiàng)目有關(guān)的都需要定義成變量，再?gòu)淖兞坷镞M(jìn)行讀取，不要在通用腳本里寫死。
node {try{stage('檢出代碼'){//從git倉(cāng)庫(kù)中檢出代碼git branch: "${BRANCH}",credentialsId: 'xxxxx-xxxx-xxxx-xxxx-xxxxxxx', url: "${REPO_URL}"loadProjectConfig();}stage('編譯'){//這里是構(gòu)建，你可以調(diào)用job入?yún)⒒蛘唔?xiàng)目配置的參數(shù)，比如：echo "項(xiàng)目名字 ${APP_CHINESE_NAME}"//可以判斷if (Boolean.valueOf("${IS_USE_CODE_CHECK}")) {echo "需要靜態(tài)代碼檢查"} else {echo "不需要靜態(tài)代碼檢查"}}stage('存檔'){//這個(gè)演示的Android的項(xiàng)目，實(shí)際使用中，請(qǐng)根據(jù)自己的產(chǎn)物確定def apk = getShEchoResult ("find ./lineup/build/outputs/apk -name '*.apk'")def artifactsDir="artifacts"//存放產(chǎn)物的文件夾sh "mkdir ${artifactsDir}"sh "mv ${apk} ${artifactsDir}"archiveArtifacts "${artifactsDir}/*"}stage('通知負(fù)責(zé)人'){emailext body: "構(gòu)建項(xiàng)目:${BUILD_URL}\r\n構(gòu)建完成", subject: '構(gòu)建結(jié)果通知【成功】', to: "${EMAIL}"}} catch (e) {emailext body: "構(gòu)建項(xiàng)目:${BUILD_URL}\r\n構(gòu)建失敗，\r\n錯(cuò)誤消息：${e.toString()}", subject: '構(gòu)建結(jié)果通知【失敗】', to: "${EMAIL}"} finally{// 清空工作空間cleanWs notFailBuild: true}}// 獲取 shell 命令輸出內(nèi)容 def getShEchoResult(cmd) {def getShEchoResultCmd = "ECHO_RESULT=`${cmd}`\necho \${ECHO_RESULT}"return sh (script: getShEchoResultCmd,returnStdout: true).trim() }//加載項(xiàng)目里面的配置文件 def loadProjectConfig(){def jenkinsConfigFile="./jenkins.groovy"if (fileExists("${jenkinsConfigFile}")) {load "${jenkinsConfigFile}"echo "找到打包參數(shù)文件${jenkinsConfigFile}，加載成功"} else {echo "${jenkinsConfigFile}不存在,請(qǐng)?jiān)陧?xiàng)目${jenkinsConfigFile}里面配置打包參數(shù)"sh "exit 1"} }輕輕的點(diǎn)兩下Build with Parameters -> 開始構(gòu)建，然后等幾分鐘的時(shí)間，就能夠收到郵件。
五、其他構(gòu)建結(jié)構(gòu)
以上，僅僅是針對(duì)我們當(dāng)前遇到問題的一種不錯(cuò)的解決方案，可能并不完全適用于所有場(chǎng)景，但是可以根據(jù)上面的結(jié)構(gòu)進(jìn)行調(diào)整，比如：
- 根據(jù)stage拆分出不同的Pipeline腳本，這樣方便CI的維護(hù)，一個(gè)或者幾個(gè)人維護(hù)構(gòu)建中的一個(gè)stage；
- 把構(gòu)建過程中的stage做成普通的自由風(fēng)格的軟件項(xiàng)目的job，把它們作為基礎(chǔ)服務(wù)，在Pipeline中調(diào)用這些基礎(chǔ)服務(wù)等。
六、當(dāng)遇上React Native
當(dāng)項(xiàng)目引入了React Native以后，因?yàn)榧夹g(shù)棧的原因，React Native的頁面是由前端團(tuán)隊(duì)開發(fā)，但容器和原生組件是Android團(tuán)隊(duì)維護(hù)，構(gòu)建流程也發(fā)生了一些變化。
方案對(duì)比
| 手動(dòng)拷貝 | 等JsBundle構(gòu)建好了，再手動(dòng)把構(gòu)建完成的產(chǎn)物，拷貝到Native工程里面 | 1. 每次手動(dòng)操作，比較麻煩，效率低，容易出錯(cuò)<br />2. 涉及到跨端合作，每次要去前端團(tuán)隊(duì)主動(dòng)拿JsBundle<br />3. Git不適合管理大文件和二進(jìn)制文件 | 簡(jiǎn)單粗暴 |
| 使用submodule保存構(gòu)建好的JsBundle | 直接把JsBundle放在Native倉(cāng)庫(kù)的一個(gè)submodule里面，由前端團(tuán)隊(duì)主動(dòng)更新，每次更新Native的時(shí)候，直接就拿到了最新的JsBundle | 1. 簡(jiǎn)單無開發(fā)成本<br />2. 不方便單獨(dú)控制JsBundle的版本<br />3. Git不適合管理大文件和二進(jìn)制文件 | 前端團(tuán)隊(duì)可以主動(dòng)更新JsBundle |
| 使用submodule管理JsBundle的源碼 | 直接把JsBundle的源碼放在Native倉(cāng)庫(kù)的一個(gè)submodule里面，由前端團(tuán)隊(duì)開發(fā)更新，每次構(gòu)建Native的時(shí)候，先構(gòu)構(gòu)建JsBundle | 1. 不方便單獨(dú)控制JsBundle的版本<br />2. 即使JsBundle無更新，也需要構(gòu)建，構(gòu)建速度慢，浪費(fèi)資源 | 方便靈活 |
| 分開構(gòu)建，產(chǎn)物存檔 | JsBundle和Native分開構(gòu)建，構(gòu)建完了的JsBundle分版本存檔，Native構(gòu)建的時(shí)候，直接去下載構(gòu)建好了的JsBundle版本 | 1. 通過配置管理JsBundle，解放Git<br />2. 方便Jenkins構(gòu)建的時(shí)候，動(dòng)態(tài)配置需要的JsBundle版本 | 1. 需要花費(fèi)時(shí)間建立流程<br />2. 需要開發(fā)Gradle的JsBundle下載插件 |
前端團(tuán)隊(duì)開發(fā)頁面，構(gòu)建后生成JsBundle，Android團(tuán)隊(duì)拿到前端構(gòu)建的JsBundle，一起打包生成最終的產(chǎn)物。 在我們開發(fā)過程中，JsBundle修改以后，不一定需要修改Native，Native構(gòu)建的時(shí)候，也不一定每次都需要重新構(gòu)建JsBundle。并且這兩個(gè)部分由兩個(gè)團(tuán)隊(duì)負(fù)責(zé)，各自獨(dú)立發(fā)版，構(gòu)建的時(shí)候也應(yīng)該獨(dú)立構(gòu)建，不應(yīng)該融合到一起。
綜合對(duì)比，我們選擇了使用分開構(gòu)建的方式來實(shí)現(xiàn)。
分開構(gòu)建
因?yàn)樾枰珠_發(fā)布版本，所以JsBundle的構(gòu)建和Native的構(gòu)建要分開，使用兩個(gè)不同的job來完成，這樣也方便兩個(gè)團(tuán)隊(duì)自行操作，避免相互影響。 JsBundle的構(gòu)建，也可以參考上文提到的Pipeline的構(gòu)建方式來做，這里不再贅述。 在獨(dú)立構(gòu)建以后，怎么才能組合到一起呢？我們是這樣思考的：JsBundle構(gòu)建以后，分版本的儲(chǔ)存在一個(gè)地方，供Native在構(gòu)建時(shí)下載需要版本的JsBundle，大致的流程如下：
這個(gè)流程有兩個(gè)核心，一個(gè)是構(gòu)建的JsBundle歸檔存儲(chǔ)，一個(gè)是在Native構(gòu)建時(shí)去下載。
JsBundle歸檔存儲(chǔ)
| 直接存檔在Jenkins上面 | 1. JsBundle不能匯總瀏覽<br>2. Jenkins很多人可能要下載，命名帶有版本號(hào)，時(shí)間，分支等，命名不統(tǒng)一，不方便構(gòu)建下載地址<br>3. 下載Jenkins上面的產(chǎn)物需要登陸授權(quán)，比較麻煩 | 1. 實(shí)現(xiàn)簡(jiǎn)單，一句代碼就搞定，成本低 |
| 自己構(gòu)建一個(gè)存儲(chǔ)服務(wù) | 1. 工程大，開發(fā)成本高<br>2. 維護(hù)起來麻煩 | 可擴(kuò)展，靈活性高 |
| MSS<br>(美團(tuán)存儲(chǔ)服務(wù)) | 無 | 1. 儲(chǔ)存空間大<br>2. 可靠性高，配合CDN下載速度快<br>3. 維護(hù)成本低， 價(jià)格便宜 |
這里我們選擇了MSS。 上傳文件到MSS，可以使用s3cmd，但畢竟不是每個(gè)Slave上面都有安裝，通用性不強(qiáng)。為了保證穩(wěn)定可靠，這里基于MSS的SDK寫個(gè)小工具即可，比較簡(jiǎn)單，幾行代碼就可以搞定。
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("請(qǐng)依次輸入：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里構(gòu)建完成后，調(diào)用這個(gè)工具就可以了。 當(dāng)然，JsBundle也分類型，在調(diào)試的時(shí)候可能隨時(shí)需要更新，這些JsBundle不需要永久保存，一段時(shí)間后就可以刪除了。在刪除時(shí)，可以參考MSS生命周期管理。所以，我們?cè)跇?gòu)建JsBundle的job里，添加一個(gè)參數(shù)來區(qū)分。
//根據(jù)TYPE，上傳到不同的bucket里面 def bucket = "rn-bundle-prod" if ("${TYPE}" == "dev") {bucket = "rn-bundle-dev" //有生命周期管理，一段時(shí)間后自動(dòng)刪除 } 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構(gòu)建時(shí)JsBundle的下載
為了實(shí)現(xiàn)構(gòu)建時(shí)能夠自動(dòng)下載，我們寫了一個(gè)Gradle的插件。 首先要在build.gradle里面配置插件依賴：
classpath 'com.zjiecode:rn-bundle-gradle-plugin:0.0.1'在需要的Module應(yīng)用插件：
apply plugin: 'mt-rn-bundle-download'在build.gradle里面配置JsBundle的信息：
RNDownloadConfig {//遠(yuǎn)程文件目錄,因?yàn)橛卸喾N類型，所以這里可以填多個(gè)。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"//版本號(hào)，這里使用的是打包JsBundle的BUILD_NUMBERfileName = 'xxxx.android.bundle-%s.zip' //遠(yuǎn)程文件的文件名,%s會(huì)用上面的version來填充outFile = 'xxxx/src/main/assets/JsBundle/xxxx.android.bundle.zip' // 下載后的存儲(chǔ)路徑，相對(duì)于項(xiàng)目根目錄 }插件會(huì)在package的task前面，插入一個(gè)下載的task，task讀取上面的配置信息，在打包階段檢查是否已經(jīng)存在這個(gè)版本的JsBundle。如果不存在，就會(huì)去歸檔的JsBundle里，下載我們需要的JsBundle。 當(dāng)然，這里的version可以使用上文介紹的注入構(gòu)建信息的方式，通過job參數(shù)的方式進(jìn)行注入。這樣在Jenkins構(gòu)建Native時(shí)，就可以動(dòng)態(tài)地填寫需要JsBundle的版本了。 這個(gè)Gradle插件，我們已經(jīng)放到到了github倉(cāng)庫(kù)，你可以基于此修改，當(dāng)然，也歡迎PR。 https://github.com/zjiecode/rn-bundle-gradle-plugin
六、總結(jié)
我們把一個(gè)構(gòu)建分成了好幾個(gè)部分，帶來的好處如下：
- 核心構(gòu)建過程，只需要維護(hù)一份，減輕維護(hù)工作；
- 方便多個(gè)人維護(hù)構(gòu)建CI，避免Pipeline代碼被覆蓋；
- 方便構(gòu)建job的版本管理，比如要修復(fù)某個(gè)已經(jīng)發(fā)布的版本，可以很方便切換到發(fā)布版本時(shí)候用的Pipeline腳本版本；
- 每個(gè)項(xiàng)目，配置也比較靈活，如果項(xiàng)目配置不夠靈活，可以嘗試定義更多的變量；
- 構(gòu)建過程可視化，方便針對(duì)性優(yōu)化和錯(cuò)誤定位等。
當(dāng)然，Pipeline也存在一些弊端，比如：
- 語法不夠友好，但好在Jenkins提供了一個(gè)比較強(qiáng)大的幫助工具（Pipeline Syntax）；
- 代碼測(cè)試繁瑣，沒有本地運(yùn)行環(huán)境，每次測(cè)試都需要提交運(yùn)行一個(gè)job，等等。
當(dāng)項(xiàng)目集成了React Native時(shí)，配合Pipeline，我們可以把JsBundle的構(gòu)建產(chǎn)物上傳到MSS歸檔。在構(gòu)建Native的時(shí)候 ，可以動(dòng)態(tài)地下載。
七、作者
張杰，美團(tuán)點(diǎn)評(píng)高級(jí)Android工程師，2017年加入餐飲平臺(tái)成都研發(fā)中心，主要負(fù)責(zé)餐飲平臺(tái)B端應(yīng)用開發(fā)。 王浩，美團(tuán)點(diǎn)評(píng)高級(jí)Android工程師，2017年加入餐飲平臺(tái)成都研發(fā)中心，主要負(fù)責(zé)餐飲平臺(tái)B端應(yīng)用開發(fā)。
八、招聘廣告
本文作者來自美團(tuán)成都研發(fā)中心（是的，我們?cè)诔啥冀ㄑ邪l(fā)中心啦）。我們?cè)诔啥加斜姸嗪蠖恕⑶岸撕蜏y(cè)試的崗位正在招人，歡迎大家投遞簡(jiǎn)歷：songyanwei@meituan.com。
轉(zhuǎn)載于:https://my.oschina.net/meituantech/blog/1922037
總結(jié)
以上是生活随笔為你收集整理的Jenkins的Pipeline脚本在美团餐饮SaaS中的实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： IT网址大全
- 下一篇： React开发（178）:ant des