CI/CD簡介
CI/CD 是一種持續開發軟件的方法，側重于軟件開發過程中的自動化，可以不斷地進行構建、測試和部署代碼。使用這種方法，從新代碼開發到部署，可以減少人工干預甚至不用干預
CI(Continuous Integration)：持續集成，也就是當每一次更改的代碼被推送到遠程分支后，可以創建一組腳本來自動地構建和測試這些更改，確保這些更改可以通過一些基本的準則，減少引入錯誤的機會
CD：
(Continuous Delivery)：持續交付，在持續集成的基礎上更進一步，當每一次更改的代碼落庫后，不僅會構建和測試，也會進行部署，但是部署需要人工干預，手動的有目的進行部署
(Continuous Deployment)：持續部署，持續集成之外的另一個步驟，類似于持續交付。不同之處在于，它不是手動部署應用程序，而是將其設置為自動部署。不需要人為干預
Gitlab CI/CD 也就是 Gitlab 提供了上面的 CI/CD 能力，可以進行持續集成，持續交付和持續部署
GitLab?CI/CD?工作流程
簡單說就是開發者在push或者merge代碼到指定分支的時候，會觸發CI/CD，GitLab CI/CD配置文件（.gitlab-ci.yml）中的Job需要通過GitLab-Runner來執行，執行過后的產物可以直接用來部署。這里會涉及Pipeline 、Stages、Jobs幾個概念
Pipelines：流水線?(在根目錄包含.gitlab-ci.yml文件的代碼push | merge時候會生成對應的流水線)
Stages：階段 (定義什么時候執行Jobs，比如：在build階段執行代碼編譯打包任務)
Jobs：任務是GitLab CI系統中可以獨立控制并運行的最小單位?(定義了該做什么，比如：編譯和測試代碼)
流水線包含一個或多個階段，每個階段又可以有多個任務，這就是他們之間的一個關系。每個Job可以指定用來執行它的Runner，同一個Stage的多個Job可并發執行，Job中至少要包含script元素用來編寫該任務運行的腳本，only元素用來指定能觸發CI/CD的代碼分支，tags元素用來指定該Job用哪個Runner來執行
如果同一個Stage中的所有Job都執行成功，Pipeline就會進入下一個Stage；如果一個Stage中的任何一個Job執行失敗，Pipeline就不會進入下一個Stage，提前結束
前面有說到Job是需要GitLab-Runner才能運行起來的，那么它們是怎么關聯起來的呢？
上面這張圖采用docker來安裝GitLab-Runner，然后將GitLab的實例URL和Token在GitLab-Runner上進行注冊，這樣GitLab和GitLab-Runner就能夠關聯上
GitLab-Runner注冊Runners主要有兩種方式：
1、在GitLab的admin area進入Runners菜單，里面就會有GitLab?Instance URL和Token
2、進到具體代碼倉庫，點開setting菜單，再進入CI/CD中的Runners，里面也會有GitLab Instance URL和Token
Runner注冊成功后會在GitLab的Runners列表中找到
GitLab CI/CD完整執行過程如下：
1、編寫CI/CD配置文件.gitlab-ci.yml，GitLab會檢測到它，配置文件里可指定可觸發CI/CD的代碼分支
2、在push或者merge代碼到上述指定的分支，會觸發CI/CD流程，就會生成一個對應的Pipeline
3、GitLab-Runner就會將代碼拉進來執行Pipeline中的Job，每個Job可指定用來執行它的Runner
4、Runner會初始化Excutor，然后通過git把GitLab的代碼倉庫拉過來，按照.gitlab-ci.yml里定義的任務來執行
5、本項目把Runner執行后的產物通過掛載的方式，把打包后的代碼掛載到Nginx的根目錄中，這樣就完成了自動化部署
Runner執行Job過程：
總結
GitLab CI/CD最主要的兩個步驟就是編寫.gitlab-ci.yml，然后到GitLab-Runner中注冊Runner，Runner可以是一個虛擬機，物理機，docker容器，或者一個容器集群。GitLab與Runner之間通過API進行通信，因此只需要Runner所在的機器有網絡并且可以訪問GitLab服務器即可
參考資料
https://docs.gitlab.com/ee/ci
https://docs.gitlab.com/runner/register
https://zhuanlan.zhihu.com/p/441581000
喜歡的話別忘了?分享、點贊、收藏?三連~
歡迎關注公眾號?前端進階體驗?收獲更多優質文章~
