本文對應用程序設計中常見的組件及其作用進行了介紹。
簡介#
從 GitLab 8.0 開始，GitLab CI 就已經集成在 GitLab 中，我們只要在項目中添加一個 .gitlab-ci.yml 文件，然後添加一個 Runner，即可進行持續集成。 而且隨著 GitLab 的升級，GitLab CI 變得越來越強大，本文將介紹如何使用 GitLab CI 進行持續集成。
一些概念#
在介紹 GitLab CI 之前，我們先看看一些持續集成相關的概念。
Pipeline#
一次 Pipeline 其實相當於一次構建任務，裡面可以包含多個流程，如安裝依賴、運行測試、編譯、部署測試伺服器、部署生產伺服器等流程。 任何提交或者 Merge Request 的合併都可以觸發 Pipeline，如下圖所示
+------------------+ +----------------+
| | trigger | |
| Commit / MR +---------->+ Pipeline |
| | | |
+------------------+ +----------------+
Stages#
Stages 表示構建階段，說白了就是上面提到的流程。 我們可以在一次 Pipeline 中定義多個 Stages，這些 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 | |
| +---------+ +---------+ +---------+ |
| |
+------------------------------------------+
簡介#
配置好 Runner 之後，我們要做的事情就是在項目根目錄中添加 .gitlab-ci.yml 文件了。 當我們添加了 .gitlab-ci.yml 文件後，每次提交代碼或者合併 MR 都會自動運行構建任務了。
還記得 Pipeline 是怎麼觸發的嗎？Pipeline 也是通過提交代碼或者合併 MR 來觸發的！ 那麼 Pipeline 和 .gitlab-ci.yml 有什麼關係呢？ 其實 .gitlab-ci.yml 就是在定義 Pipeline 而已拉！
基本寫法#
我們先來看看 .gitlab-ci.yml 是怎麼寫的：
# 定義 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"
寫起來很簡單吧！用 stages 關鍵字來定義 Pipeline 中的各個構建階段，然後用一些非關鍵字來定義 jobs。 每個 job 中可以可以再用 stage 關鍵字來指定該 job 對應哪個 stage。 job 裡面的 script 關鍵字是最關鍵的地方了，也是每個 job 中必須要包含的，它表示每個 job 要執行的命令。
回想一下我們之前提到的 Stages 和 Jobs 的關係，然後猜猜上面例子的運行結果？
I am job2
I am in build stage
I am job1
I am in test stage
沒錯，根據我們在 stages 中的定義，build 階段要在 test 階段之前運行，所以 stage 的 jobs 會先運行，之後才會運行 stage 的 jobs。
常用的關鍵字#
下面介紹一些常用的關鍵字，想要更加詳盡的內容請前往 官方文檔
stages
定義 Stages，默認有三個 Stages，分別是 build, test, deploy。
types
stages 的別名。
before_script
定義任何 Jobs 運行前都會執行的命令。
after_script**
要求 GitLab 8.7+ 和 GitLab Runner 1.2+
定義任何 Jobs 運行完後都會執行的命令。
variables && Job.variables
要求 GitLab Runner 0.5.0+
定義環境變量。 如果定義了 Job 級別的環境變量的話，該 Job 會優先使用 Job 級別的環境變量。
cache && Job.cache
要求 GitLab Runner 0.7.0+
定義需要緩存的文件。 每個 Job 開始的時候，Runner 都會刪掉 .gitignore 裡面的文件。 如果有些文件 (如 node_modules/) 需要多個 Jobs 共用的話，我們只能讓每個 Job 都先執行一遍 npm install。 這樣很不方便，因此我們需要對這些文件進行緩存。緩存了的文件除了可以跨 Jobs 使用外，還可以跨 Pipeline 使用。
具體用法請查看 官方文檔。
Job.script
定義 Job 要運行的命令，必填項。
Job.stage
定義 Job 的 stage，默認為 test。
Job.artifacts
定義 Job 中生成的附件。 當該 Job 運行成功後，生成的文件可以作為附件 (如生成的二進制文件) 保留下來，打包發送到 GitLab，之後我們可以在 GitLab 的項目頁面下下載該附件。 注意，不要把 artifacts 和 cache 混淆了。