基本概念：GitLab Project ≈ GitHub Repository
對於從 GitHub 轉移到 GitLab 的團隊而言，最常見的第一個疑問就是術語差異。在 GitHub 的世界裡，程式碼的基本單位叫做 Repository（倉庫）；而在 GitLab 中，對應的概念稱為 Project（專案）。
兩者功能上幾乎等價——都用來存放程式碼、管理 Issue、設定 CI/CD Pipeline。只是 GitLab 的 Project 還進一步整合了 Wiki、Container Registry、Package Registry 等功能，讓它成為更完整的 DevOps 平台入口。理解這個對應關係，是順利上手 GitLab 的第一步。
💡 GitLab 的層級結構為：Group → Sub-Group → Project，類似於 GitHub 的 Organization → Repository 架構，但支援更深層的巢狀分組，更適合大型企業的多部門管理。
GitLab 管理員的日常維運工作
企業自架（Self-Managed）的 GitLab 需要專職的系統管理員負責日常維運，確保平台穩定、安全且高效運行。以下是管理員需要定期關注的核心工作項目：
- 🖥️ 系統健康監控：定期檢查 CPU 使用率與 RAM 記憶體狀況，確保伺服器資源充足，避免因資源不足導致服務中斷。
- 💾 備份與還原：定期執行 GitLab 備份流程，並定期演練還原程序，確保災難發生時能迅速復原。
- 🏃 Runner 可用性管理：監控 CI/CD Runner 的可用數量。若有 Job 卡住（Stuck），需手動清除，避免 Pipeline 堆積。
- 📦 磁碟空間監控：追蹤 Git 儲存庫、Container Registry、Build Artifacts 的磁碟佔用量，適時清理過期資料。
- ⬆️ 版本升級：定期評估並執行 GitLab 版本升級，取得安全性修補與新功能，需依照官方升級路徑逐版操作。
- 👤 帳號離職停用：免費版 GitLab 不會自動同步 AD，人員離職後須手動在 GitLab 停用或刪除帳號，防止資安風險。
⚠️ AD 帳號同步限制（免費版）： GitLab 免費版不具備 AD 自動同步功能。人員異動（離職、調職）須由管理員手動在 GitLab 後台停用帳號，建議建立 SOP 納入 HR 離職流程，避免帳號殘留的資安隱患。此外，建立 Group 雖為選擇性設定，但建議提早規劃好分組架構，後期調整成本較高。
專案管理員建立專案的完整流程
每個新專案啟動時，專案管理員需要依照以下步驟在 GitLab 中完成設定，確保權限架構清晰、成員能順利存取。
- 建立 Group 或 Sub-Group 依照組織架構（如部門、產品線）建立 Group，Sub-Group 可用來進一步細分團隊或子專案。
- 建立 Project 並加入對應 Group 在指定 Group 下新建 Project，命名建議遵守統一規範（如小寫 kebab-case），方便後續管理。
- 設定 Visibility Level（可見度） 依據專案屬性選擇適當的可見等級，詳見下表說明。
- 加入成員並設定角色 將相關開發人員、QA、PM 加入專案，並依職責賦予 Developer、Maintainer 等角色權限。
- 設定 CI/CD（選擇性） 依需求建立
.gitlab-ci.yml設定檔，定義 Pipeline 階段與 Runner 指派規則。
Visibility Level 可見度等級說明：
| 等級 | 可存取對象 | 適用情境 |
|---|---|---|
| Private | 僅限被明確加入的成員 | 敏感商業專案、核心系統、有保密需求的程式碼庫 |
| Internal | 所有已登入 GitLab 的帳號 | 公司內部共用工具庫、文件、標準模板 |
| Public | 無需登入，任何人皆可瀏覽 | 開源專案、對外公開的技術文件或 SDK |
新人報到流程：從 AD 到 GitLab 存取
由於免費版 GitLab 不支援 AD 自動同步，新進人員的 GitLab 帳號建立方式與付費版不同，需要特別注意以下流程：
- IT 在 Active Directory（AD）建立帳號 完成 AD 帳號建立，設定好 Email、部門等基本資訊。
- 新人首次登入 GitLab，帳號自動建立 免費版不會預先同步 AD 帳號，GitLab 帳號在新人第一次以 AD 憑證登入時才會自動建立於系統中。
- 專案管理員手動將人員加入專案 管理員在 Project 的 Members 設定頁面搜尋新人帳號，指定對應角色後加入。
- 設定完成，新人登入即可看到專案內容 新人重新登入後，即可在首頁看到已加入的專案，開始正常使用。
📌 建議在新人報到 SOP 中明確標注「第一次登入 GitLab」這個步驟，否則管理員在 Members 頁面搜尋時會找不到該帳號（帳號尚未建立），容易造成流程卡關。
CI 常見觸發情境
GitLab CI 的 Pipeline 可以透過多種事件觸發，合理配置觸發條件能大幅提升團隊的交付效率：
- 🔀 支線合併主線：開發人員的 Feature Branch 發起 Merge Request 時，自動觸發測試流程，確保程式碼品質才能合入主線。
- 🕐 每日排程執行：利用 GitLab Scheduled Pipelines，在下班時段自動產生測試報表或執行耗時的整合測試，不佔用工作時段資源。
- 🚀 Release 發版時：在 GitLab 上建立 Release Tag 時觸發完整的 CI 測試與 CD 部署流程，確保每次發版都經過完整驗證。
CI/CD 完整上線流程詳解
以下是一個完整的 GitLab CI/CD 上線流程，從開發人員 Push Code 開始，一路到部署至正式環境的每個關鍵環節：
- 開發人員 Push Code 將功能分支推送到 GitLab，發起 Merge Request（MR）請求合入主線。
- Merge Request 觸發 CI 自動測試 GitLab Runner 自動執行單元測試、Lint 檢查等流程，結果即時回報於 MR 頁面。
- 測試通過 → 管理員審核並 Approve Merge 管理員 Code Review 完成後按下同意合併，程式碼正式進入主線（main/master）。
- GitLab 自動 Deploy 到測試環境 合併觸發 CD Pipeline，程式碼自動部署至 Staging 測試環境，供 QA 團隊驗收。
- QA 驗收完成 QA 在測試環境確認功能正確、無異常，簽核通過進入發版流程。
- 管理員建立 Release → 觸發 CI 測試 建立版本 Tag 與 Release，再次觸發完整 CI 測試，確保最終版本無誤。
- 手動按下 Deploy 按鈕 正式環境部署採用手動觸發（Manual Gate），需由授權人員確認後才執行，增加一道人工防護。
- 自動部署到正式環境 GitLab Runner 執行部署腳本，完成正式環境更新，整個流程有完整的 Pipeline 記錄可供稽核。
⚠️ 正式環境的 Deploy 步驟建議設為
when: manual，並搭配 GitLab 的 Protected Environments 功能，限制只有特定角色（如 Maintainer）才能按下部署按鈕，防止誤操作。
GitLab 外網連線控管
CI/CD Pipeline 執行過程中，GitLab Runner 通常需要連線到網際網路——例如下載 npm 套件、拉取 Docker Image、呼叫外部 API 等。企業環境中，這類對外連線應透過白名單（Allowlist）嚴格控管，降低資安風險。
常見需要開通的對外網域範例：
# Package Registries
registry.npmjs.org
pypi.org
repo.maven.apache.org
# Container Image Registries
registry.hub.docker.com
ghcr.io
# GitLab.com（若有使用 SaaS Runner 或整合）
gitlab.com
# 其他依專案需求自行新增
your-internal-nexus.company.com🌐 建議與資安團隊協作，在 Proxy 或防火牆層設定白名單，而非直接開通全部對外存取。同時可考慮架設 內部 Nexus / Artifactory 作為套件快取，減少對公開 Registry 的依賴，也能在網路隔離環境下正常執行 CI/CD。