終於，我們到了鐵人賽的最後一天，在回顧與總結之前，艦長要和期望看到深入內容的讀者致歉，因為一開始艦長還很雄心壯志的想要好好的利用這 30 天分享 GitLab 的深入內容，並期望能帶入一個假想的案例貫穿 30 天讓大家能更有體會。不過沒想到真的參賽之後才發現自己太天真了，要將案例與 GitLab 的功能搭配寫成文章，拿捏好內容深度，最後在分配成 30 天按進度釋出，這整件事情沒有想像中的容易。於是在且戰且走，每天微調修正的狀況下，這個玩轉 GitLab 的系列文，就變成這幅面貌了。如果你一開始是被艦長撰寫的系列文簡介吸引過來，但最後卻發現內容深度不足的話，只能向你說聲抱歉了！
最後一天，先讓我們快速的回顧前面 29 天到底都談了些什麼？
我們建立了對於 GitLab 的基本認識、初步了解該如何評估是要使用 gitlab.com 或自行架設 GitLab Server，同時也認識了 GitLab 的管理後台與使用者權限。
接著，是原本計畫要貫穿 30 天的 GitLab Workflow 及相關功能的介紹。
另外，針對關鍵要素的 CI/CD 也同樣花費了數天逐一介紹每個 Stage 與 CI Job，並且提出了一些在規劃 CI/CD Pipeline 時需要思考的關鍵問題。
最後，我們一起試用了 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 的使用經驗。
鐵人賽，我們明⋯⋯年⋯⋯⋯⋯再看狀況決定要不要見面～
自 2021 年 12 月 12 日開始，我就一直想要將原發佈在 iT 邦幫忙的鐵人賽系列文章搬移至 https://gitlab-book.tw 並補充說明文章內容已有過期之處。
因為當初參加 iThome 鐵人賽時，GitLab 仍在 12 版，但如今 GitLab 已更新好幾版了，需要提醒大家注意一下。
本文已完成搬遷
iThome鐵人賽
看影片追技術