提及到持續整合工具，想到的有jenkins、buildbot、gitlab ci，本文就來講講gitlab ci~
首先先掃盲：
什麼是持續整合？
持續整合指的是，頻繁地（一天多次）將程式碼整合到主幹。
持續整合的好處主要有兩個：
快速發現錯誤：
每完成一點更新，就整合到主幹，可以快速發現錯誤，定位錯誤也比較容易。
防止分支大幅偏離主幹：
如果不是經常整合，主幹又在不斷更新，會導致以後整合的難度變大，甚至難以整合。
簡單總結：
減少風險、減少重複過程、專案更加透明
常見的持續整合系統組成
一個完整的構建系統必須包括：
- 一個自動構建過程，包括自動編譯、分發、部署和測試等。
- 一個程式碼儲存庫，即需要版本控制軟體來保障程式碼的可維護性，同時作為構建過程的素材庫。
- 一個持續整合伺服器
GitLab CI介紹
GitLab CI
GitLab CI 是 GitLab 提供的持續整合服務，只要在你的倉庫根目錄 建立一個.gitlab-ci.yml 檔案， 併為該專案指派一個Runner，當有合併請求或者 push的時候就會觸發build。
GitLab-Runner
這個是指令碼執行的承載者，.gitlab-ci.yml的script部分的執行就是由runner來負責的。
GitLab-CI瀏覽過專案裡的.gitlab-ci.yml檔案之後，根據裡面的規則，分配到各個Runner來執行相應的指令碼script。
.gitlab-ci.yml
.gitlab-ci.yml 檔案定義GitLab runner要做哪些操作。
預設有3個[stages(階段)]: build、test、deploy。
Pipelines
Pipelines是定義於.gitlab-ci.yml中的不同階段的不同任務。
把Pipelines理解為流水線，流水線包含有多個階段（stages），每個階段包含有一個或多個工序（jobs），
比如先購料、組裝、測試、包裝再上線銷售，每一次push或者MR都要經過流水線之後才可以合格出廠。
而.gitlab-ci.yml正是定義了這條流水線有哪些階段，每個階段要做什麼~
+------------------+ +----------------+
| | trigger | |
| Commit / MR +---------->+ Pipeline |
| | | |
+------------------+ +----------------+
複製程式碼Stages
Stages 表示構建階段，說白了就是上面提到的流程。
我們可以在一次 Pipeline 中定義多個 Stages，每個Stage可以完成不同的任務。
Stages有下面的特點：
所有 Stages 會按照順序執行，即當一個 Stage 完成後，下一個 Stage 才會開始
只有當所有 Stages 完成後，該構建任務 (Pipeline) 才會成功
如果任何一個 Stage 失敗，那麼後面的 Stages 不會執行，該構建任務 (Pipeline) 失敗
複製程式碼因此，Stages 和 Pipeline 的關係就是：
+--------------------------------------------------------+
| |
| Pipeline |
| |
| +-----------+ +------------+ +------------+ |
| | Stage 1 |---->| Stage 2 |----->| Stage 3 | |
| +-----------+ +------------+ +------------+ |
| |
+--------------------------------------------------------+
複製程式碼Jobs
Jobs 表示構建工作，表示某個 Stage 裡面執行的工作。
我們可以在 Stages 裡面定義多個 Jobs，這些 Jobs 會有以下特點：
相同 Stage 中的 Jobs 會並行執行
相同 Stage 中的 Jobs 都執行成功時，該 Stage 才會成功
如果任何一個 Job 失敗，那麼該 Stage 失敗，即該構建任務 (Pipeline) 失敗
複製程式碼所以，Jobs 和 Stage 的關係圖就是：
+------------------------------------------+
| |
| Stage 1 |
| |
| +---------+ +---------+ +---------+ |
| | Job 1 | | Job 2 | | Job 3 | |
| +---------+ +---------+ +---------+ |
| |
+------------------------------------------+
複製程式碼簡單的說，要讓CI工作可總結為以下幾點:
1）在倉庫根目錄建立一個名為.gitlab-ci.yml 的檔案
2）為該專案配置一個Runner
完成上面的步驟後，每次push程式碼到Git倉庫， Runner就會自動開始pipeline。
CI基本原理
持續整合基本原理實際上非常簡單：
- 1.檢測到 git 有新的程式碼提交（定時檢測或主動觸發），生成任務
- 2.agent（真正幹活的程式，可以分佈在多臺機器） 領取任務，拉取程式碼，執行一段指令碼（無論是單元測試還是 APP 打包，都可以用指令碼完成）
- 3.展示結果：成功與否、測試覆蓋率、apk ipa 下載連結等
安裝及配置
1.安裝runner
本文以win10舉例：
首先，下載gitlab-ci-multi-runner-windows-amd64，並將其放到C:\CI
下載地址： https://gitlab-ci-multi-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-ci-multi-runner-windows-amd64.exe
Centos： 安裝gitlab-ci-multi-runner：
-
新增yum源
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash 複製程式碼
執行後長這樣：
只要不報錯或者提示找不到的話，就可以了，那接下來就安裝了~
yum install gitlab-ci-multi-runner
複製程式碼註冊等步驟則跟Windows一致~ 2.獲取gitlab的runners
點選一個專案->Settings->CI/CD->Runners setting,點選Expand
3.配置runner
回到剛剛配置的目錄，樓主是在C:\CI
執行下面的命令：
gitlab-ci-multi-runner-windows-amd64.exe register
複製程式碼如果是Linux則如下：
gitlab-ci-multi-runner register
複製程式碼然後會要求輸入一堆東西，如下圖：
1）輸入Gitlab CI地址
2）輸入專案CI的token
3）輸入Runner的描述
4）輸入Runner的標籤
5）是否執行無標記的構，預設false，後面可以改
6）是否將Runner跟當前專案繫結，預設false，如果不繫結，即為共享runner，後面可以改~
7）輸入Runner執行語言
複製程式碼執行完後，會發現CI目錄會多了個config.toml的檔案，裡面就是剛剛的配置資訊~
如果是Linux，Runner資訊放哪裡呢？
- 如果是以root使用者身份執行gitlab-ci-multi-runner register，那麼配置檔案預設是/etc/gitlab-runner/config.toml
- 如果是以非root使用者身份執行gitlab-ci-multi-runner register，那麼配置檔案預設是~/.gitlab-runner/config.toml
- 又或者是在當前工作目錄下./config.toml
下面需要開啟runner服務~
在CI目錄下，分別輸入install跟start命令：
gitlab-ci-multi-runner-windows-amd64.exe install
gitlab-ci-multi-runner-windows-amd64.exe start
複製程式碼如果需要停止，把start修改成stop即可~
輸入完畢後，只要沒有報錯，則說明成功，然後回到gitlab專案-Runner Settings上，會發現多了個runner的資訊：
到此為止，runner設定完成了~
關於其他平臺的安裝到註冊，詳情請看官網詳細介紹，大同小異： https://docs.gitlab.com/runner/install/
4）.gitlab-ci.yml
如上面介紹的一樣，.gitlab-ci.yml 檔案定義GitLab runner要做哪些操作；
它位於專案的根目錄。
一個簡單的.gitlab-ci.yml
stages:
- test
job1:
stage: test
script:
- echo "jb1111112222"
複製程式碼很簡單，定義了一個叫job1的jobs，stages裡面是定義任務執行的順序，但上面體現不出來，而這個job1裡面就是輸出jb1111112222這串玩意~
注意：.gitlab-ci.yml是一個YAML檔案，所以必須要格外注意鎖緊。使用空格，而不是tabs。
假如是這樣呢？
# 定義 stages
stages:
- build
- test
# 定義 job
job1:
stage: test
script:
- echo "I am job1"
- echo "I am in test stage"
# 定義 job
job2:
stage: build
script:
- echo "I am job2"
- echo "I am in build stage"
理所當然的，上面的執行結果就是這樣：
I am job2
I am in build stage
I am job1
I am in test stage
根據在 stages 中的定義，build 階段要在 test 階段之前執行，所以 stage:build 的 jobs 會先執行，
之後才會執行 stage:test 的 jobs。
複製程式碼檔案建立好了，內容也定義好了，然後需要新增到git倉庫~
git add .gitlab-ci.yml
git commit -m "Add .gitlab-ci.yml"
git push origin master
複製程式碼下面為常用的關鍵字資訊，一般熟悉就夠用了：
有關更多關鍵字資訊，請看下面的文章： https://segmentfault.com/a/1190000010442764#articleHeader5
5）檢視pipeline和jobs的狀態
成功的配置好Runner後，你應該檢視最後一次提交後的狀態，從pending、到執行中、成功或失敗。
點選進入具體job的執行情況：
gitlab CI大致就介紹完畢了，剩下的就是定義.gitlab-ci.yml檔案，做想執行的事情~
遇到的問題
1）gitlab ci結果顯示亂碼
暫時沒找到解決方案
2）runner無端端離線，然後一直start失敗，一直提示gitlab-runner: Service is running!， 即使重灌gitlab-runner也不能解決問題
現象：
輸入gitlab-runner start,卡住很久，然後沒有任何日誌輸出
解決方案: 這種問題，第一思路就是找error log，但是找了很久都沒找到error log檔案；
最後晚上找到一條命令：
journalctl -u gitlab-runner
複製程式碼輸入後，會顯示log：
然後再輸入:
gitlab-runner start
gitlab-runner status
複製程式碼然後就能看到久違的is running!!
感動啊~為了看到這個提示，都不知道找了多少方法，果然，看log才是王道~
3）gitlab 上一直顯示pending
原因： 在註冊gitlab runner的時候，有一步是：
那沒有標記tag的程式碼提交時不會觸發gitlab runner，測試階段，最好填寫true；
那如果是已經建立好的runner，不想重新註冊，怎麼辦？
開啟對應的runner介面，點選編輯圖示，把run untagged jobs勾上即可；
步驟： projects-settings-CI/CD-Runners settings
這樣，就不會再是pending的狀態了~
4）許可權不夠，無法建立目錄
這個目錄就是問題2手動建立的目錄，手動chmod 777 /home/gitlab-runner即可
謝謝大家~