Jenkins x GitLab CI

Jenkins x GitLab CI
yihsuanchen@kkbox.com

Yihsuan Chen
Software Engineer in Test

對於初學者來說，Jenkins 會比 GitLab CI 來的友善
e.g. 建立 Job
Jenkins
● 可單獨使用 GUI 介面完成一切設定
GitLab CI
● 需要 commit .gitlab-ci.yml 至 GitLab repo

● GUI 介面操作方便
○ 建立
○ 刪除
○ 更動
● 無 GUI 設置介面
○ .gitlab-ci.yml

Jenkinsfile.groovy .gitlab-ci.yml

● 共有超過 1600 個 Plugins
○ Integration
○ Notification
○ Report
○ Trend
● 無 Plugins Library
○ 客製

在 Jenkins Plugins 頁
速速滑到底部大概要花 15.93 秒。

有 Plugin 很方便
但過度依賴也可能會是場災難。

dev 炸了
幫我試試上一版 master 會不會發生。

Jenkins 的自由度較 GitLab CI 高
e.g. 尋找 master 上一個版本
Jenkins
● 找版本可從 Build List 下手，可在 Build List 加註 Description
GitLab CI
● 找版本需從 Branch Commit 下手，Pipeline List 較為混雜

Jenkins 的 Artifacts 集中度較高
e.g. 下載 master 上一個版本的 APKs 與測試報告
Jenkins
● Artifacts 以 Build 為單位，可一次下載所有 Artifacts
GitLab CI
● Artifacts 以 Stage 為單位，分別下載對應 Stage 的 Artifacts

● Build List 自由度高
● Artifacts 較為集中
○ Artifacts per Build
● Pipeline List 較為混雜
● Artifacts 相對分散
○ Artifacts per Stage

GitLab CI 有著嚴謹的 Job 驅動性
e.g. Pipeline 什麼時機點會被啟動
Jenkins
● 被動性質，需自行設定 Upstream、Poll SCM、Hook Script
GitLab CI
● 主動性質，所有 Branch 的所有 Commit 都會執行 CI

所有分支的所有更動都 Trigger CI
聽起來很囉唆、很浪費時間？

嗨，你的 PR 我看完了，測試有跑過了嗎
有啊，當然有（自信滿滿）
好喔
好喔，我不信
$ git pull
$ git checkout xiao-ming-branch
$ <run test>
（以下言論不代表本台立場）
好喔

GitLab Repo MR
● 所有程式碼皆被一樣的流程審核過
● 去除任何 MR 提出者遺忘執行測試的疑慮
● 且 GitLab MR 頁面的資料透明度是個強大的助手
Code Reviewer 只需要專心的 Code Review

● Build Triggers 需自行設定
○ Upstream
○ Poll SCM
○ Hook Script
● 與 MR 流程是分開的
● Build Triggers 嚴謹
○ All branches
○ All commits
● GitLab MR 整合性好

GitLab CI 與 Docker 有著優異的整合性
e.g. Web e2e test
Jenkins
● 找台 Slave 安裝 Node 環境，且需注意環境 Setup & Teardown
GitLab CI
● 找個 Node 的 Docker Image，且無需在意環境是否乾淨

● 環境需自行建立
● 需額外考量
○ Setup
○ Teardown
● 環境整合 Docker Image
● Container 用完即拋棄

Jenkins 與 GitLab CI 皆有相關支援
e.g. Slave / Runner Setup
Jenkins
● 從 Master 上設定（Slave Label、Workspace Dir、Job Limit）
GitLab CI
● 從 Runner 上設定（Runner Label、Workspace Dir、Job Limit）

GitLab CI 支援 Locked (Private) Runner
e.g. Slave / Runner 使用權
Jenkins
● 只要知道 Slave Label，任何人皆可以使用
GitLab CI
● 可將 Runner 額外設定為 Shared (Public) or Locked (Private)

Jenkins 有額外揭露 Busy Status
e.g. 如果 Job Limit 為 1，且又有第 2 個 Job 進來
Jenkins
● 有 Build Executor Status 紀錄 Slave 使用狀態，並會顯示佇列
GitLab CI
● 僅有 Pending Status，難以從 CI 上直觀的看到 Runner Status

● 皆有支援基礎配置
● 有 Build Executor 狀態列
● 皆有支援基礎配置
● 有支援 Locked Runner

Pros
● GUI 介面
○ 初學者學習上較為直觀
● Plugin Library
○ 第三方整合
○ 有美麗的 Report, Trend
● 版本管理
○ Build List 自由度高
○ Artifact 取得方便
● Slave Status
○ 提供 Build Executor Status 幫
助觀測 Slave 使用狀態
Cons
● Groovy
○ CI Script 較不簡潔
● Plugin Library
○ 大量使用容易踩到相容性問題
● 環境設置
○ Slave 環境需自行製作
○ 需考量 Setup 及 Teardown
● 版本建置
○ 需自行設定 Build Triggers
● Slave permission
○ Slave 使用權限較寬鬆

Pros
● Yaml
○ CI Script 撰寫清晰、成本低
● 環境設置
○ 與 Docker 有高度整合性
○ 拋棄式 Container 環境，不必多
做 Setup 或 Teardown
● 版本建置
○ CI 建置規範較為嚴謹
○ 與 GitLab Repo 整合優異
● Locked Runner
○ Runner 存取權較嚴謹
Cons
● All by .gitlab-ci.yml
○ 所有異動皆需通動 commit
● 沒有 Plugins
○ 任何第三方整合皆需客製化
○ 沒有任何 Report, Trend
● 版本管理
○ Pipeline List 較為混雜
○ Artifact 以 Stage 為單位，下載
較不方便
● 沒有提供 Runner 使用狀態
○ 僅有 Pending Status，較無從
得知 Runner 當前使用情況

1. 自己玩玩 Jenkins & GitLab CI

2. 觀察哪類型的專案比較適合哪一套工具

3. 整理出屬於自己的抉擇習慣

現在的我，會依照這個流程抉擇

我會依序詢問自己以下 2 個根本問題
1.是否為 GitLab Repo？
○ 若為「是」 - GitLab CI（ MR 流程、Docker 整合、Pipeline 驅動性）
○ 若為「否」 - Jenkins
2.是否很需要版本紀錄、趨勢圖、測試報告、通知系統、第三方整合？
○ 若為「是」 - Jenkins（ Plugins Library ）
○ 若為「否」 - GitLab CI

4. 過程中一定會有很多掙扎

「如果再如果」
1.如果專案不在 GitLab 上，那嘗試搬到 GitLab 上會需要做哪些事情？
2.如果捨棄掉第三方整合的東西，真的會怎麼樣嗎？
3.如果還是需要 Plugin，自己打造的成本該怎麼預估？
4.如果...
5.如果再如果...

5. 驅使自己更深沉的認識 CI 工具的特性

沒有最厲害的工具，只有最適合的工具
● 熟悉 Jenkins 及 GitLab CI 特性
○ 簡單的專案
○ Legacy 專案
● 應證看看你所體會的優缺點是否相符
○ Jenkins 的優缺點
○ GitLab CI 的優缺點

想體會
但要先各寫一份 CI Script？
小聲問：太麻煩了，給抄嗎？

git@github.com:yihsuan-chen-s/jenkins-x-gitlabci.git

Jenkins x GitLab CI

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Jenkins x GitLab CI

Similar to Jenkins x GitLab CI (20)

Jenkins x GitLab CI