回顧與總結

本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。

本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。 鐵人賽原文網址：https://ithelp.ithome.com.tw/articles/10227606）

終於，我們到了鐵人賽的最後一天，在回顧與總結之前，艦長要和期望看到深入內容的讀者致歉，因為一開始艦長還很雄心壯志的想要好好的利用這 30 天分享 GitLab 的深入內容，並期望能帶入一個假想的案例貫穿 30 天讓大家能更有體會。不過沒想到真的參賽之後才發現自己太天真了，要將案例與 GitLab 的功能搭配寫成文章，拿捏好內容深度，最後在分配成 30 天按進度釋出，這整件事情沒有想像中的容易。於是在且戰且走，每天微調修正的狀況下，這個玩轉 GitLab 的系列文，就變成這幅面貌了。如果你一開始是被艦長撰寫的系列文簡介吸引過來，但最後卻發現內容深度不足的話，只能向你說聲抱歉了！

回顧

最後一天，先讓我們快速的回顧前面 29 天到底都談了些什麼？

我們建立了對於 GitLab 的基本認識、初步了解該如何評估是要使用 gitlab.com 或自行架設 GitLab Server，同時也認識了 GitLab 的管理後台與使用者權限。

GitLab 介紹

基本認識

GitLab 管理與權限

接著，是原本計畫要貫穿 30 天的 GitLab Workflow 及相關功能的介紹。

GitLab Workflow

另外，針對關鍵要素的 CI/CD 也同樣花費了數天逐一介紹每個 Stage 與 CI Job，並且提出了一些在規劃 CI/CD Pipeline 時需要思考的關鍵問題。

GitLab CI

最後，我們一起試用了 GitLab 目前最新潮的功能 Auto DevOps，體驗它的神奇之處。

GitLab Auto DevOps

總結

從上面的回顧我們可以發現，在 29 天的文章中，篇幅最多的主題是 CI/CD Pipeline，而且真要說的話 Auto DevOps 的內容也同樣可以歸類為 CI/CD Pipeline，這樣相加一算 CI/CD Pipeline 的文章共有 16 篇，等於這 29 天有超過一半的文章都在談 CI/CD。

對於上面結果，其實也不用感到意外，因為 CI Pipeline 對於現代的軟體開發就是如此的重要。早在 DevOps 一詞開始全球火紅(2009)之前，Continuous intergration 的觀念就已經存在(2007)，如何打造更有品質的產品（程式）、如何提升團隊的生產力，並非是近幾年才出現在市面的觀念，早在 10 幾年前就已經有很多前輩持續在探討這些問題，而 CI/CD Pipeline 則是有助於實踐這些觀念且歷史悠久的一項工具。

雖然我們都知道 DevOps != CI/CD，但 CI/CD 絕對是企業與團隊在實踐 DevOps 時，需要面對的重要關鍵。在高談闊論 DevOps 之前，不如先花點時間將團隊的 CI Pipeline 搞定，畢竟就如艦長貫穿多篇文章使用的那個假想情境，隨著團隊與專案的發展，CI/CD Pipeline 本身也必須與時俱進的「持續改善」。

最後，再次提醒大家，雖然 GitLab 與 GitLab Workflow 目前看起來前途一片大好，但它們終究是一種工具，也不是沒有可能在一夜之間，就被下一個新工具給取代。因此就如艦長在文章「CI Service 掛掉時怎麼辦？」提過的，GitLab 為我們提供的 Workflow 一條龍服務有它的方便之處，但也別忘了為自己保留抽換工具的彈性，役物而不役於物。

30 天玩轉 GitLab 系列文就在此結束，感謝大家不嫌棄的一直收看到了現在，希望這 30 天的文章能對大家有所幫助。我知道有很多高手都是默默潛水，如果你也是 GitLab 的使用者，有任何經驗想要分享也歡迎與我交流，也歡迎你加入 DevOps Taiwan 社群，在社群分享更多 GitLab 的使用經驗。

鐵人賽，我們明⋯⋯年⋯⋯⋯⋯再看狀況決定要不要見面～

← GitLab Cycle Analytics & Charts