2019獨角獸企業重金招聘Python工程師標準>>> 
在本系列文章中，我們將探討在容器時代如何在基于Docker的環境中創建連貫的工作流程和流水線來簡化大規模項目的部署。另外，我們還將詳細介紹如何利用Docker和Rancher自動化處理這些工作流。
在上文《將構建環境容器化》中，我們開始了構建持續集成流水線的第一步工作——構建系統（Build System）的創建。我們分析了【Build】這一環節的常見的三大挑戰——依賴管理、管理環境依賴、復雜項目的漫長構建時間，以及如何用傳統工具與方法解決這些問題。接著，我們分享了如何利用Docker創建容器化的構建系統以更輕松地解決那些傳統挑戰，包括如何將構建環境容器化、如何使用Docker打包應用程序、如何使用Docker Compose創建構建環境，最終創造一個可重復的、集中管理的、良好隔離的、并行化的構建系統。
現在我們已經將【Build】系統創建好了，那么在本文中，我們將為示例的應用創建一個持續集成流水線。這樣我們既可以確保遵循最佳實踐，又可以確保彼此沖突的那些變化不會相互作用、引發問題。不過，在我們為代碼建立持續集成之前，我們先花一點時間討論如何將代碼劃分到分支中。
分支模式
在我們實現持續集成流水線的自動化時，一個需要考慮的重點是團隊遵循的開發模式。這個模式通常由團隊如何使用版本控制系統來決定。由于我們的應用程序托管在git倉庫中，因此我們使用git-flow模型進行分支、版本化以及發布我們的應用程序。它是基于git倉庫上最常用的模型之一。簡而言之，該模型的思想是維護兩個分支：一個開發（者）分支，一個主分支。每當我們想開發新功能時，就會從開發分支創建出新的分支，并在功能開發完成時，將它合并回來。所有功能分支都有開發人員單獨管理。一旦將代碼提交到開發分支，CI服務器將負責確保分支始終能夠編譯、通過自動化測試并且可以在服務器上進行QA測試和評審。當我們準備進行發布時，可以從開發分支創建一個發布，并將其合并到主分支中。被發布的特定的commit hash也會使用版本號進行標記。被標記好的發布項接著就可以被推送到Staging/Beta或者生產環境中。
下面我們將使用git-flow工具來幫助管理我們的git分支。安裝git-flow請參考這里的說明：https://github.com/nvie/gitflow/wiki/Installation。安裝好git-flow，你就可以通過下面所示的git flow init命令配置你的倉庫。Git flow會問一些問題，我們建議你使用默認的設置即可。執行過git-flow命令后，它將創建一個開發分支（如果原先沒有開發分支的話），并將其檢出作為工作分支。
現在，我們使用git flow輸入git flow feature start [feature-name]命令創建一個新功能。通常做法是用ticket/issue id用作功能的名稱。比如，如果你使用的是Jira處理ticket，那么ticket id（例如，MSP-123）就可以作為功能名稱。你還會發現當你使用git-flow創建新功能時，它將自動切換到功能分支。
到了這一步，你可以去完成該功能所需的全部內容，然后運行自動化測試套件以確保一切正常運轉。一旦你準備好發布工作，只需告訴git-flow去完成這一功能即可。根據你對該功能的實際需要，你想要進行多少次提交都可以。在我的這個示例中，從我們的目的來看，我們只需更新README文件，并通過輸入“git flow feature finish MSP-123”來完成更新。
需要注意的是，git flow合并了開發分支的功能，刪除了功能分支并且返回到了開發分支。此時，你可以將開發分支推送到遠程倉庫（git push origin develop:develop）。 當你提交了開發分支，CI服務器就會接管持續集成流水線。對于更大的團隊來說，一種更合適的模式是在完成功能之前將功能分支推送到遠程，讓它們經評審（review）后，使用pull request來合并到開發分支中。
使用Jenkins創建CI流水線
在這一節，我們假設你已啟動并運行了一個Jenkins集群。如果沒有的話，你可以在這里使用官方的Jenkins鏡像：https://hub.docker.com/_/jenkins/ ，在這里可以看到更多關于建立可擴展Jenkins集群的內容：https://rancher.com/deploying-a-scalable-jenkins-cluster-with-docker-and-rancher/ 。在你有了運行的Jenkins集群后，我們需要在Jenkins服務器上安裝下面的插件和依賴項：
Jenkins Plugins 2.32.2+
-
Git Parameter Plugin 0.8.0+
-
Parameterized Trigger Plugin 2.33+
-
Copy Artifact Plugin 1.38.1+
-
Build Pipeline Plugin 1.5.6+
-
Mask Passwords Plugin 2.9+
Docker 1.13.1+
Docker Compose 1.11.1+
安裝好需要的插件后，我們就可以在【Build流水線】中創建最初的三個任務：編譯、打包和集成測試。這些將作為我們持續集成和部署系統的起點。
構建應用
序列中的第一個任務將會在每次提交后從源碼控制中檢出最新的代碼并且確保其可編譯。它還會運行單元測試。如果要在我們的示例項目中設置第一個任務，選擇New Item->Freestyle Project。進入項目配置視圖中，選擇General選項卡以及“The project is parameterized”選項。添加一個叫做GO_AUTH_VERSION的git參數，將參數類型設置為Branch（分支）或者Tag（標記）。接下來選擇Advanced配置參數，使用Tag Filter設置獲取匹配“v”的所有標記（比如v2.0）。將Default Value設置成develop（開發分支）。這將有助于從Git獲取版本標簽列表，并為該任務填充選項菜單。如果該任務要在沒有給定值的情況下自動觸發，那么GO_AUTH_VERSION默認設成develop（開發）分支。
接下來，在Source Code Management選項卡部分添加倉庫url，指定分支為${GO_AUTH_VERSION}，這樣手動構建時將會使用git參數來選擇分支或標記進行構建及設置輪詢間隔。這樣一來，Jenkins就會持續追蹤我們開發分支的未來所有更改，在我們的CI（和CD）流水線中自動觸發第一個任務。這里要注意的是，GO_AUTH_VERSION的默認值（比如開發分支）將用于自動檢測到的更改。
現在在Build選項卡部分選擇Add Build Step > Execute Shell并從本章前面部分復制docker run命令粘貼到這。這樣可以從Github獲得最新的代碼，并將代碼構建到go-auth可執行文件中。這里需要安裝并運行docker。如果你使用的是Linux服務器，可能還需要在docker客戶機命令中添加sudo以便能夠訪問docker守護進程。
在構建步驟之后，我們需要添加兩個后續步驟，其中Archive the Artifacts（工件歸檔）將go-auth二進制文件和幫助腳本歸檔到項目中。我們在任務中需要指定下列的工件進行歸檔。
接著我們使用Trigger parameterized builds（觸發器參數化構建）啟動流水線中的下一個任務，如下圖所示。在添加Trigger parameterized build時，請確保是從Add Parameters中添加的Current build parameters。這樣可以讓當前任務的全部參數（比如GO_AUTH_VERSION）用于下一個任務。請留意在Trigger parameterized build部分中用于下游任務的參數名稱，我們將在下面的步驟中用到。
構建任務的日志輸出應該像下面展示的這樣。你可以看到我們使用了docker化的容器來執行構建。構建時將使用go fmt來修復代碼中任何格式的不一致，并且執行我們的單元測試。如果出現測試失敗或者編譯不通過，Jenkins就會檢測到失敗。此外，你應該通過email或者chat integrations（例如Hipchat或者Slack）設置通知，這樣在構建失敗時就能通知到你的團隊，快速地修復它。
打包應用
代碼編譯通過了，接下來我們就能將它打包進Docker容器中。創建打包任務的方式是，選擇New Item > Freestyle Project并給你的第二個任務起一個名稱，該名稱對應于在先前任務中指定的內容。和之前一樣，該任務也是一個帶有GO_AUTH_VERSION參數的參數化構建。要注意的是，這里和所有后續的任務中，GO_AUTH_VERSION只是一個默認值為develop（開發分支）的string參數。我們希望它的值是從上游傳過來的。
和之前一樣，添加構建步驟來執行shell。注意這里你不需要指定SCM設置，因為我們將從前一個構建生成的工件中提取所需的二進制文件和腳本。注意一下，我們這里是先創建未標記的usman/go-auth，之后再重新標記，這樣我們就可以在后面執行集成測試，搭建好未打標記的容器環境。
為了構建Docker容器，我們還需要前一步中構建的可執行文件。為此，我們增加一個構建步驟復制上游構建中的工件。這樣可以保證我們有可用于Docker構建命令的可執行文件，該命令可以打包到Docker容器中。注意這里我們選擇了flatten目錄來保證所有工件都復制到當前項目的根目錄中。
我們一直在使用GO_AUTH_VERSION變量標記我們正在構建的鏡像。在默認情況下，開發分支的變更，總會構建usman/go-auth：develop并覆蓋現有的鏡像。在下一章中，我們會發布應用程序的新版本并重新審視這個流水線。
和之前相同，使用了Trigger parameterized builds下（包含了Current build parameters）的后構建（post-build）來觸發流水線中的下一個任務，該任務將使用我們剛剛構建好的Docker容器以及在之前章節中詳述的Docker Compose來執行集成測試。
執行集成測試
接下來是執行集成測試，先要創建一個新任務。和打包任務相同，新任務是一個使用GO_AUTH_VERSION string變量的參數化構建。然后從構建任務中復制工件。這一次我們將使用上面的Docker Compose模板來搭建一個多容器測試環境，并對我們的代碼執行集成測試。集成測試（不同于單元測試）通常是與正在測試的代碼完全隔離的。因此，我們會用到一個shell腳本，它可以針對我們的測試環境執行http查詢。在執行shell命令中，將目錄修改為go-auth并執行integrationtest.sh。
腳本的內容可以在這里找到：https://github.com/usmanismail/go-messenger/blob/master/go-auth/integration-test.sh。我們用Docker Compose搭建我們的環境，然后使用curl發送http請求到搭建的容器中。這項任務的日志將會和下圖顯示的相似。Compose將會啟動一個數據庫容器，并將它連接到goauth容器。數據庫連接之后你應該會看到一些列“Pass: …”信息，說明各項測試都在運行和驗證。測試完成后，compose模板將會自行清理數據庫和go-auth容器。
經過了三個任務的設置，你就可以在Jenkins視圖中選擇【+選項卡】，選擇build pipeline view來創建一個新的構建流水線視圖。在彈出的配置界面中，選擇你編譯/構建的任務作為初始任務，然后選擇ok。現在你應該能看到CI流水線已經成型。這將給你一個可視化引導，展示每個提交是如何通過你的構建和部署流水線的。
當你更改開發分支時，你會注意到流水線是由Jenkins自動觸發的。如果要手動觸發流水線，選擇你第一個（構建）任務，運行它。系統會要求你選擇git參數的值（比如GO_AUTH_VERSION）。不指定的話會執行默認值，并且會運行針對開發分支中最新內容的CI流水線。當然，你可以直接在流水線視圖中單擊“Run”。
我們快速回顧一下到現在為止我們所做的工作。我們通過以下步驟為我們的應用程序創建了CI流水線：
-
使用git-flow添加新功能，并將他們合并到開發分支中。
-
跟蹤開發分支的變化，在一個容器化環境中構建我們的應用程序
-
將我們的應用程序打包到docker容器中
-
使用Docker Compose搭建短生命周期環境
-
執行集成測試以及清理環境
通過上面的CI流水線，每當新功能（或者修復）合并到開發分支時，CI流水線就會執行上述所有的步驟，創建出“usman/go-auth:develop” Docker鏡像。此外，我們在接下來的章節中將構建更深層的集成部署流水線。另外因為該視圖有清晰的測試階段，你還可以使用此視圖將應用程序版本推廣到各種部署環境中。
總 結
在本章中，我們分享了如何利用Docker為我們的項目創建一個持續集成流水線，該流水線是集中管理的、可測試的，并且在機器和時間上可重復。我們能夠根據需要對各種組件的環境依賴進行隔離。這是我們未來部署一條更長的基于Docker構建和部署的流水線的起點，我們將在下一次的文章中繼續構建這一流水線的余下部分并將過程經驗記錄下來。
我們流水線的下一步是創建持續部署，后續文章我們將展示如何使用Rancher部署整個服務器環境來運行代碼，我們還將介紹如何為大型項目設置長期運行的測試環境和持續部署流水線的最佳實踐。
