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

時間 2019-11-08

標籤 jenkins pipeline 腳本餐飲 saas 實踐欄目自動化構建简体版

原文原文鏈接

1、背景

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

目前，咱們團隊主要負責開發和維護多個Android項目，並且每一個項目都須要構建，每一個構建流程很是相似但又存在必定的差別。好比構建的流程大概以下：java

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

整個流程大致上是相同的，可是又存在一些差別。好比有的構建能夠沒有單元測試，有的構建不用觸發自動化測試，並且構建結果通知的負責人也不一樣。若是使用自由風格軟件項目的普通構建，每一個項目都要創建一個job來處理流程（可能會調用其餘job）。node

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

固然，若是有項目集成了React Native，還須要構建JsBundle。在Native修改之後，JsBundle不必定會有更新，若是是構建Native的時候一塊兒構建JsBundle，就會形成不少資源浪費。而且直接把JsBundle這類大文件放在Native的Git倉庫裏，也不是特別合適。git

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

2、Pipeline的介紹

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

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

Stage Viewshell

3、使用Pipeline構建

新建一個Pipeline項目，寫入Pipeline的構建腳本，就像下面這樣: 後端

對於單個項目來講，使用這樣的Pipeline來構建可以知足絕大部分需求，可是這樣作也有不少缺陷，包括：

多個項目的Pipeline打包腳本不能公用，致使一個項目寫一份腳本，維護比較麻煩。一個變更，須要修改多個job的腳本；
多我的維護構建job的時候，可能會覆蓋彼此的代碼；
修改腳本失敗之後，沒法回滾到上個版本；
沒法進行構建腳本的版本管理，老版本發修復版本須要構建，可能和如今用的job版本已經不同了，等等。

4、把Pipeline當代碼寫

既然存在缺陷，咱們就要找更好的方式，其實Jenkins提供了一個更優雅的管理Pipeline腳本的方式，在配置項目Pipeline的時候，選擇Pipeline script from SCM，就像下面這樣： api

這樣，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 -> 開始構建，而後等幾分鐘的時間，就可以收到郵件。

5、其餘構建結構

以上，僅僅是針對咱們當前遇到問題的一種不錯的解決方案，可能並不徹底適用於全部場景，可是能夠根據上面的結構進行調整，好比：

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

6、當趕上React Native

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

方案對比

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

前端團隊開發頁面，構建後生成JsBundle，Android團隊拿到前端構建的JsBundle，一塊兒打包生成最終的產物。在咱們開發過程當中，JsBundle修改之後，不必定須要修改Native，Native構建的時候，也不必定每次都須要從新構建JsBundle。而且這兩個部分由兩個團隊負責，各自獨立發版，構建的時候也應該獨立構建，不該該融合到一塊兒。

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

分開構建

由於須要分開發布版本，因此JsBundle的構建和Native的構建要分開，使用兩個不一樣的job來完成，這樣也方便兩個團隊自行操做，避免相互影響。 JsBundle的構建，也能夠參考上文提到的Pipeline的構建方式來作，這裏再也不贅述。在獨立構建之後，怎麼才能組合到一塊兒呢？咱們是這樣思考的：JsBundle構建之後，分版本的儲存在一個地方，供Native在構建時下載須要版本的JsBundle，大體的流程以下：

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

JsBundle歸檔存儲

方案	缺點	優勢
直接存檔在Jenkins上面	1. JsBundle不能彙總瀏覽 2. Jenkins不少人可能要下載，命名帶有版本號，時間，分支等，命名不統一，不方便構建下載地址 3. 下載Jenkins上面的產物須要登錄受權，比較麻煩	1. 實現簡單，一句代碼就搞定，成本低
本身構建一個存儲服務	1. 工程大，開發成本高 2. 維護起來麻煩	可擴展，靈活性高
MSS (美團存儲服務)	無	1. 儲存空間大 2. 可靠性高，配合CDN下載速度快 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_NUMBER
    fileName = '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。 github.com/zjiecode/rn…