本片文章主要初步介紹什么是CICD流程，並且把整個流程進行拆分理解整個流程的跑通過程。
1.CICD概述
- 什么是CICD呢？
簡單的說CICD就是持續集成自動構建自動測試自動部署.
從概念上就可以看出，CICD主要由四個部分組成代碼集成、打包構建、自動測試、自動部署。我們只需要把代碼推送到gitlab遠程分支上gitlab自動幫我們做好后面的所有流程，不需要我們手動參與，一看就非常的方便。
- CICD是怎么實現的呢？
要實現CICD得實現以下幾個部分：
- 遠程倉庫功能
- pipeline
- runner
基本的流程如下：
碼農將代碼推送到遠程倉庫上， 然后觸發pipline流水線通知注冊的runner執行pipeline上定義的任務。
2.CI部分
CI就是代碼集成也就是階段性地向代碼存庫中集成最新的代碼，其中gitlab的作用和github等代碼托管平台的作用是一模一樣的。
3.pipeline
gitlab中pipline翻譯過來就是管道，我們知道管道很小水流是順序流出的，也就是我們定義構建任務，測試任務，部署任務然后任務按照順序執行，那么如果定義任務呢？
在項目根目錄下新建一個 .gitlab-ci.yml 文件，在文件中我們可以定義任務執行階段，及每個階段執行的任務等信息，如下代碼
before_script:
- bundle install
after_script:
- rm secrets
stages:
- build
- test
- deploy
job1:
stage: build
script:
- execute-script-for-job1
only:
- master
tags:
- docker
job2:
stage: test
script:
- echo zhe shi ce shi jie daun
job3:
stage: deploy
script:
- echo 這是自動部署階段
那上面的例子舉例，我們就在管道中定義了3個階段，分別為build、test、deploy三個階段，然后我們定義job1任務為build階段執行的，script為執行的命令，job2為test階段執行的任務，job3為deply階段執行的任務。
當然真實生產時.gitlab-ci.yml文件肯定比這復雜很多，具體復雜的屬性可以根據官方文檔查看。
我們定義好了pieline，那么任務的執行者是誰呢？這就是接下來的runner角色了。
4.runner
runner一看名字我們就知道他是我們每個階段任務的真實執行者，那它是怎么工作的呢？
- 首先我們需要在需要部署代碼的機器上安裝runner（不可以和gitlab服務一個機器）
- 然后啟動runner
- 啟動runner程序，並注冊到gitlab服務器上（建立runner和gitlab服務器的連接）
- 選擇一個excutor執行方式（比如是shell的本地執行，還是docker容器內執行，還是k8s等方式，初練選shell會好一點就是本地執行）
- 完成、等待觸發
5.總結
我們只需要把整個CICD流程結構化區分一下思路就會瞬間清晰很多了，比如分成提交代碼的部分（碼農）、遠程倉庫（gitlab）、定義執行流程（pipeline）、任務執行者（runner）。
然后我們在想一下分成這幾個部分以后，整個流程是怎么串起來來的呢？
- 碼農提交代碼到遠程倉庫（我們本地）
- 觸發pipeline任務通知runner去執行（gitlab服務器）
- runner根據任務階段順序執行對應的任務（目標代碼部署服務器）
基於上述我們就很快把整個CICD流程給弄清晰了，可以把一些簡單的項目執行起來了，
但道路且長，上述只是簡單的理解CICD的流程概念，如果需上手真實復雜的項目，還需要閱讀官方文檔如涉及容器，k8s，不同分支不同runnner，runner分類，excutor分類，等等比較細粒度的規則。