這是第二篇有關GitLab的文章，我想就工程師的角度帶你走進這項技術細節。
先前從工程師的角度討論為什麼月是忙碌的工程師要導入這項自動化技術，有興趣的可以往前看 [GitLab 系列] 軟體工程師不得不學會的 GitLab – Eidolon’s 成長手札 (eidolon168.com)。
建立專案的例行工作流水線 (Pipeline)
如同專案的分工，你必須明確定義要請GitLab做什麼，成功、失敗的條件是什麼?
這些所謂繁瑣的例行性工作就是流水線，你可以把任務分成多個階段與工作，並且定義相關的變數與觸發條件。
這份流水線工作就是所謂的 Pipeline 由 .gitlab-ci.yml 檔案定義。
我們先來一個 nodejs 的 express 專案來看看整體流水線架構
image: node:latest
stages:
- enviroment-set-up
- run-project-test
enviroment-set-up:
stage: enviroment-set-up
script:
- npm install
run-project-test:
stage: run-project-test
only:
- master
variables: # <---- override any env var you want here
PORT: "3000"
NODE_ENV: "production"
script:
- npm test
看到 yml 的副檔名格式，相信第一時間聯想到的就是 docker, Kubernetes 這類的宣告文件。
沒錯，GitLab也是透過類似這項技術來達到環境快速建置與專案程式的工作。基本構成要件包含:
- 執行環境- image
通常這邊是你的專案環境，指的就是系統需要幫你預載哪些程式。這部分是與dockerhub相同，所以你不需要為了測試安裝一個遠端主機，安裝作業系統，寫一堆腳本幫你安裝開發環境與設定環境變數，直接從映像檔庫拉下來即可 - 定義整條流水線的工作階段- stage
就像生產線一樣，你可以將工作分成幾個階段，每個階段有他所負責的工作任務。以此範例為例，我簡單拆成環境建置與專案測試等2個階段 - 定義你的階段工作任務
這裡我讓階段很單純，每一個階段就負責1個工作，這部分也是這份檔案的精隨。
一個工作必須透過以下關鍵字來定義這份工作的資訊細節:- 所屬工作階段- stage (必須)
- 由哪些分支觸發- only / except 等 (可選)
- 要執行哪些腳本 (必須)
- 環境變數宣告- variables (可選)
這算是比較高竿一點的玩法，因為可能這項專案要執行部署在多台叢集主機；或是考量整體服務存取機密，有些帳號密碼可以透過這邊傳入已完成後續測試作業
基本上，這樣宣告完成，流水線就完成定義啦! 其實真的滿簡單的，整理這篇目的純粹快速擷取官方文件的重要資訊，讓你可以快速入門。
所以我們試著讀懂這份流水線要請他做什麼: 我請 GitLab 在我每次 merge 到 master 分支時做兩個任務，首先幫我安裝相關來自 package.json 的所有套件，完成運行環境的事前建置；第二個工作則是跑我預先設計好的測試單元，檢查新功能的導入是否有影響到既有功能
如何將自動化測試類比到實際開發體驗?
工程師完成開發後，執行環境通常都會很混亂，為了開發需求電腦中可能有各式各樣的基礎環境，在我們的電腦運作基本上都不會有什麼問題，神奇的是到客戶電腦環境中，就發現這也卡、哪也卡。
為此實務上，你可能會請測試工程師把專案給拉下來一份到乾淨的電腦上跑。因此他會需要先把環境建置起來，接著把整個程式跑起來，看看有沒有遇到什麼狀況，再提交 issue 請你跟進排除。
現在你開發完程式不用再找人幫忙，自己也無須跳下去，只需要事先定義好，就讓電腦給你一份報告，讓你知道這個專案移轉到乾淨的電腦運行會不會遇到什麼問題，是不是超級方便有效率的!