- 前言 - Backend 與 CICD
- 什麼是 CI/CD?
- 為什麼要用 GitLab?
- GitLab CI/CD 概念與名詞
- Gitlab CI/CD YAML 檔案範例
- Gitlab CI/CD 操作範例
- 結語
- 參考資料
前言 - Backend 與 CICD
從過去的經驗來看，Backend 和 DevOps 的工作界線有些常常重疊的地方，在部份公司中 Backend 就僅止於應用的開發（純寫 code），不碰 deploy，舉凡 deploy 相關的可能最多寫完 Dockerfile 或 docker-compose.yml，剩下的就交給 DevOps 或 SRE 這些 Role。
然而也有部份公司的 Backend 是需要包辦 deploy 的，現在 AI 當道的時代，我想各個開發團隊的角色界線又會更為模糊，有 AI 輔助後，大家似乎都有了處理更多問題的能力，在工作職責的跨度上也更廣了，沒有只有誰能做什麼的情況。
又碎念扯遠了，只是想說，如果作為一位 Backend，可以懂得 CICD 的流程，在未來碰到相關工作，或是自己寫服務時，都會很有幫助的，讓我們一起來瞭解一下 Gitlab CI/CD 吧！
延伸閱讀：關於 Docker 的介紹，可以參考
什麼是 CI/CD?
CI/CD 是目前軟體開發中不可或缺的自動化流程，分別代表 Continuous Integration (持續整合) 和 Continuous Deployment/Delivery (持續部署/交付)。
- CI (持續整合)：開發者將程式碼推送至版本控制系統後，自動觸發測試、編譯等流程，以確保程式碼整合的穩定性。
- CD (持續部署/交付)：程式碼通過測試後，自動或手動將其部署至 testing 或 production ，縮短產品交付周期。
CI/CD 的目的在於縮短開發到部署的時間，減少人為錯誤，同時提高整體效率和產品品質。
延伸閱讀：軟體開發實務 - 多環境建置(multiple environments)
為什麼要用 GitLab?
GitLab 是一個功能全面的 DevOps 平台，和 Gtihub 類似，兩者都可以讓我們把程式碼推上去，不過 Github 比較專注於開源社群的經營，另外，Gitlab 有開源，也就是說，你可以在 server 上架自己團隊的 Gitlab 呦，將版本控制、CI/CD、問題追蹤等工具整合在一起。
使用 GitLab 有下面幾個優勢：
- 不需要額外工具，CI/CD 功能內建於 GitLab。
- 提供免費方案，適合小型團隊和個人專案。
- 有開源版本，可以自架團隊用的 Gitlab
GitLab CI/CD 概念與名詞
在實作 GitLab CI/CD 流程之前，先認識以下概念與名詞：
- Pipeline：在 CI/CD 流程中的最高層級，由多個 stages 組成，例如 build、test、deploy。
- Stages：Pipeline 的不同階段，例如測試階段或部署階段。
- Jobs：Pipeline 中的具體任務，例如執行單元測試或部署應用程式。
- Runners：執行 Jobs 的代理程式，Runner 可以部署於 local、cloud 或 Kubernetes。
整個 Gitlab CICD 的階層關係就像下面這樣，一個 pipline 底下會有多個 stage，一個 stage 底下會有多個 job，而 Runner 就像一台機器，專門用來執定我們定義給他的任務。
白話而言，Pipeline 就像一調運行的產線，裡面會有許多不同的階段，每個階段會有很多任務要做，Pipeline 可以被各種不同的條件觸發，像是如果有新 commit，或是有 merge 發生，這些都可以自己定義呦。
Gitlab CI/CD YAML 檔案範例
在 Gitlab 要定義 CICD 的流程很簡單，只需要在專案的 root level 放入一個名為 .gitlab-ci.yml 的檔案就完成了。
下方為 CI 的範例，通常會拆成三個 stage，分別為
build: 通常會拿來用buildDocker imagetest: 將程式碼的測試跑過一遍deploy: 把服務 deplpoy 到 server 上跑起來
在 .gitlab-ci.yml 裡頭，會先把 stage 定義出來，接著在下面列出一個個 job，並且指定 job 是屬於哪個 stage，以及 job 執行事要做的事，下面的範例就是簡單地用 echo 印出一些文字。
stages:
- build
- test
- deploy
build_job:
stage: build
script:
- echo "Building the application..."
test_job_1:
stage: test
script:
- echo "Running test 1..."
test_job_2:
stage: test
script:
- echo "Running test 2..."
deploy_job:
stage: deploy
script:
- echo "Deploying the application..."
系統預設與自訂變數
在 .gitlab-ci.yml 檔案中，可以用 $<variabel-name> 來取用定義好的變數，變數分為兩類
- 專案預設 (Predefined)
- 自訂變數 (Custom)
Gitlab 在 CI 流程有一卡車的專案預設變數可以使用，例如
$CI_REGISTRY_IMAGE：預設的 project image 路徑$CI_PIPELINE_SOURCE：觸發事件$CI_COMMIT_SHA：當前提交的 SHA- ...
完整清單可以在Predefined CI/CD variables reference 找到。
要自訂變數的話，可以在直接在 .gitlab-ci.yml 中定義或者是在 Gitlab 的 UI 後台設定，如果要在 .gitlab-ci.yml 中定義，就像下方寫法，加入一個 variables 的區塊
...
variables:
DB_HOST: "database.example.com"
API_TOKEN: $CI_API_TOKEN # 從專案預設變數引用
...
如果是要在 Gitlab 的 UI 後台設定，在點進專案後，可以從側邊欄依序找到 Settings > CI/CD > Add variable，設定的方法就像常見的環境變數一樣，定義好後，就可以在 .gitlab-ci.yml 中直接用 $ 來引用囉。
Gitlab CI/CD 操作範例
接著我們來實際用個專案跑 pipeline 體驗一下。我在自己的 Gitlab 建了一個 demo 專案，整個 repo 裡就只有 .gitlab-ci.yml 這個檔案，可以點這看到 Gitlab CICD Demo
裡頭放的 .gitlab-ci.yml 就是上方提供的範例，當我一把檔案推上去後，就成功觸發了 pipline 的運行， 詳情可以點 Build > Pipelines > Status，點下後可以看到 Pipeline 的詳細狀況
畫面顯示的就如同 yaml 所定義的，共有 3 個 stage，而在 test stage 下會有 2 個 job。
點進 job 後會看到運作的詳情，可以看到最下方確實執行了我們在 .gitlab-ci.yml 中寫下的echo "Running test 1..."，
結語
實際上的 .gitlab-ci.yml 內容會相對複雜許多，本篇我們先將概念走過一次，看完後可以對 Gitlab CI/CD 的運作有基礎認識，CI/CD 就是將程式碼開發到實際部署時的常見工作流程給自動化，是很方便的工具和實用的技能，推薦一定要來玩玩看。