上一篇文章我們介紹了 CI Lint，本文再接再厲，繼續介紹另外兩個在規劃 CI Pipeline 會用到的功能——Pipeline Editor 與 Pipeline simulation。（本文撰寫時，使用的 GitLab 版本為 13.8 。）
（本文同步發表於 Medium。）
Pipeline Editor Pipeline Editor 是 GitLab 13.8 新增的功能。（就說 13.x 一直功能大噴發～）
過去在撰寫 .gitlab-ci.yml 時，我們只能看著檔案內容，自己在腦中想像屆時 CI Pipeline 會長成何種模樣。在 Pipeline 結構單純時，用想像的還足以應付。但如果 Pipeline 較為複雜，特別是當你有使用多個 Template 或需要依據 Tags、Variables 的差異來執行不同的 CI Job 時，只靠想像可能就有點辛苦了。
因此 GitLab 為了幫助使用者可以更友善的撰寫 .gitlab-ci.yml，終於在 13.8 新增了 Pipeline Editor 這個神奇的功能。Pipeline Editor 會根據 .gitlab-ci.yml 的內容直接在 WebUI 繪製出 CI Pipeline 的模擬圖（Visualize），讓我們不用實際送出 Commit 也能一覽目前規劃好的 CI Pipeline。
讓我們從一個簡單的範例開始，在剛進入 Pipeline Editor 功能介面的 Write pipeline configuration 時，它會自動幫你帶入該 Project 之 Default branch 的 ....
相信所有的 GitLab 使用者一定都曾遇過一個狀況。即是好不容易撰寫了一份自覺完美的 .gitlab-ci.yml，但在 git push 送出 Commit 之後，卻只得到 GitLab 介面上顯示著紅色的錯誤 yaml invalid。（本文撰寫時，使用的 GitLab 版本為 13.8 。）
（本文同步發表於 Medium。）
（本來想要帥氣的展現 CI Pipeline，誰知道只看到 CI Pipeline 很糗的顯示 YAML 格式有錯！）
這種狀況不只會發生在 GitLab 新手，就連 GitLab 老手也經常發生。如果錯誤是因為寫錯 GitLab CI 專有的語法也就算了，畢竟 GitLab CI 越來越強大，有日漸複雜化的趨勢。但在真實情境中往往多半只是某一行 YAML 縮排沒正確對齊，導致出現 yaml invalid，因而白白浪費了寶貴的時間。
為了幫助使用者們能夠避免上述的狀況，GitLab 目前已提供 CI Lint 功能，讓使用者可以在送出 Commit 前，事先檢查 .gitlab-ci.yml 是否撰寫正確。
CI Lint - GitLab WebUI 如想要以 WebUI 的方式使用 CI Lint，可以在 Project > CI/CD > Pipelines 介面的右上角找到它。
WebUI 使用起來非常方便，就是一個簡易的線上編輯器，我們只要將 .gitlab-ci.yml 的內容複製貼上於此，並按下 Validate，即可得知是否撰寫正確。 按下 Validate 並通過 CI Lint 的檢查後，即可得到類似下圖的結果，CI Lint 不僅會告知你 Syntax is correct，同時也會條列你目前規劃了哪些 CI Job。 當然，如果 ....
今年艦長發了個瘋，在第二個小孩剛出生沒多久、即將舉辦 DevOpsDays Taipei 2019 （我擔任其中一位組織者）的狀態之下，參加了「第 11 屆 iT 邦幫忙鐵人賽(2019)」。
這次參賽的主題為「和艦長一起 30 天玩轉 GitLab」，本來想要用一個虛擬的團隊作為案例，分享關於 GitLab 的使用經驗，但實際上場之後才發現當初規劃的太美好，事前準備的不夠充分。雖然順利完賽，但案例規劃的並不完整、內容深度也不如計畫，最終撰寫的成果仍是較基礎的 GitLab 操作文章。
（This article has been translated into English.）
目前文章依然留存於「iT 邦幫忙」網站上，暫時先不一篇篇的搬到我私人的部落格，先用超連結的方式處理：
iT邦幫忙網站提供的30天文章列表 下面直接附上 30 篇文章連結，並做一個簡單的分類整理： （鐵人賽文章撰寫時，使用的 GitLab 版本主要是 12；後續出版為書籍《和艦長一起 30 天玩轉 GitLab》第一版時，版本為 13.x；2022 年改版《和艦長一起 30 天玩轉 GitLab》為第二版時，版本為 15.x。） 基本認識 前言 安裝 GitLab GitLab 管理與權限 Admin Area—維運 GitLab Server 的管理者後台 GitLab 的 User 與權限控管 GitLab Workflow GitLab: 從建立 Group 和 Project 開始 初探 GitLab Workflow & GitLab Flow GitLab 和 Mattermost GitLab: Issue、Issue Board 和 Kanban GitLab: To-Do List 與 Milestones GitLab: Commit & Merge Request GitLab: Issue Templates & Merge Request Templates GitLab: Project Wiki & GitLab Pages GitLab Cycle Analytics & Charts GitLab CI 架設 GitLab CI Runner GitLab: 建立第一條 CI/CD Pipeline CI/CD Pipeline 之 stage: build CI/CD Pipeline 之 stage: deploy CI/CD Pipeline 之 stage: test CI/CD Pipeline 之 stage: prod-deploy CI/CD Pipeline 之 Container CI/CD Pipeline 之 CI Service 掛掉時該怎麼辦？ GitLab CI 之 CI trigger、API 與 ChatOps GitLab CI 之 Scheduling Pipelines GitLab Auto DevOps GitLab: Auto DevOps 之牛刀小試 GitLab: Auto DevOps 之牛刀小試 2 - K8S GitLab: Auto DevOps 之牛刀小試 3 - Auto Deploy (Production) GitLab: Auto DevOps 之牛刀小試 4 - Auto Browser Performance Testing GitLab: Auto DevOps 之牛刀小試 5 - Auto Monitoring GitLab: Auto DevOps 之牛刀小試 6 - Customizing 回顧與總結 回顧與總結 以上就是 30 天鐵人賽的所有文章。...
除了 Jenkins 之外，個人排行第二感興趣的 CI Tool 是 GitLab（GitLab CI 在 GitLab 8.0 之後合併至 GitLab CE/EE）。個人目前被 GitLab 所吸引的地方是它的「單純與便捷」，如同有些人說 Jenkins 太囉唆了，Jenkins 在使用上可以設定的細節超級多（雖然你不一定每一項都會用到）；相較之下 GitLab 單純且便捷，彷彿只要在程式碼中多加一個 yaml 檔即可設定完所有 CI 流程與動作。
但，真的有這麼簡單嗎？ 所以當然要實際架設來玩玩看，才能做出更多的判斷。
2016.11.4 補充，確實就是這麼簡單，GitLab 確實是目前熱門的 CI Tool，功能越趨完整，雖然難免開始肥大化，但是未來發展不容小覷。
另外此文已經有部分過期了，建議各位閱讀之餘，還要對照最新的文件，避免有誤！
用 Docker 架設 GitLab 現在 Docker 如此盛行，要架設服務最簡單的做法就是先上 Docker Hub 搜尋現成的 Docker Image。GitLab 這種熱門專案當然不意外，一定會有現成的 Image 可以直接取用。在社群朋友的推薦之下，即找到下面這個優質的 Docker Image。
https://hub.docker.com/r/sameersbn/gitlab/ 印象中這個 Docker Image 的作者 sameersbn 是 Docker 圈內的大神之一，除了 GitLab 之外，他也做了其他很多優質的 image，大神出品，品質保證，選用他的 image 准沒錯！
大神做出來的 Docker Image 備有非常完整的使用說明，根據 Quick Start 的說明，可以直接使用作者貼心的準備的 docker-compose....