持續集成與持續部署寶典Part 2：創建持續集成流水線
在本系列文章中，我們將探討在容器時代如何在基於Docker的環境中創建連貫的工作流程和流水線來簡化大規模項目的部署。另外，我們還將詳細介紹如何利用Docker和Rancher自動化處理這些工作流。
在上文《將構建環境容器化》中，我們開始了構建持續集成流水線的第一步工作——構建系統（Build System）的創建。我們分析了【Build】這一環節的常見的三大挑戰——依賴管理、管理環境依賴、復雜項目的漫長構建時間，以及如何用傳統工具與方法解決這些問題。接著，我們分享了如何利用Docker創建容器化的構建系統以更輕松地解決那些傳統挑戰，包括如何將構建環境容器化、如何使用Docker打包應用程序、如何使用Docker Compose創建構建環境，最終創造一個可重復的、集中管理的、良好隔離的、並行化的構建系統。
現在我們已經將【Build】系統創建好了，那麽在本文中，我們將為示例的應用創建一個持續集成流水線。這樣我們既可以確保遵循最佳實踐，又可以確保彼此沖突的那些變化不會相互作用、引發問題。不過，在我們為代碼建立持續集成之前，我們先花一點時間討論如何將代碼劃分到分支中。
分支模式
在我們實現持續集成流水線的自動化時，一個需要考慮的重點是團隊遵循的開發模式。這個模式通常由團隊如何使用版本控制系統來決定。由於我們的應用程序托管在git倉庫中，因此我們使用git-flow模型進行分支、版本化以及發布我們的應用程序。它是基於git倉庫上最常用的模型之一。簡而言之，該模型的思想是維護兩個分支：一個開發（者）分支，一個主分支。
下面我們將使用git-flow工具來幫助管理我們的git分支。安裝git-flow請參考這裏的說明：https://github.com/nvie/gitflow/wiki/Installation
現在，我們使用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服務器上安裝下面的插件和依賴項：
持續集成與持續部署寶典Part 2：創建持續集成流水線