回顧與總結

本系列文是從 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 的使用經驗。

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