嗨！大家今天過得好嗎？或者應該要問大家今天都工作順暢、沒有救火 on-call 嗎？

在現在的軟體開發工作中，工程師們難免都需要和其他的夥伴一起協力工作，通常協作的對象包含了其他的開發者、前端、後端、維運、PM⋯⋯甚至是其他的團隊或企業。在這樣的情況之下，團隊是否擁有一個良好的工作流程與協作默契，對於團隊的生產力而言是非常重要的。

針對軟體開發工作流程，仿間已有數間服務供應商提供了各自的解決方案，可以幫助團隊快速的建立一條屬於自己的 Workflow；而 GitLab 正是其中一間值得期待的後起之秀。雖然 GitLab 最初對許多人而言，只是自建 Git Server 的其中一項選擇，但隨著其功能的日漸完善，如今 GitLab 已發展出名為 GitLab Workflow 的完整工作流程，已能滿足軟體開發從開發至部署的各階段需求。

（圖片來源 - https://about.gitlab.com/press/press-kit/）

GitLab 基本認識

在開始我們的 30 天旅程之前，讓我們先針對 GitLab 建立一些基本認識：

• GitLab 最初是採用 MIT 授權之免費開源軟體。現在則分為 GitLab CE（社群版）和 GitLab EE（企業版），而兩者的核心程式碼是相同的，但企業版會在核心功能之上，再疊加更多好用的進階功能。
• 使用者可以選擇自行架設 GitLab Server，或註冊使用 gitlab.com 的服務 。
• 續上，無論是自架或使用 gitlab.com，目前都分為四種付費等級；且不用擔心，兩種版本也都有免付費的等級。
• GitLab 提供的服務主要包含了 git 版本控制系統（version control system）、CI/CD Pipeline，以及其他專案管理的功能，像是 Wiki、Issue Tracking、Kanban、Burndown Chart⋯⋯。
• GitLab 的 CI/CD Pipeline 會依據使用者存放在各專案內的特定 yaml 檔自動建立。
• GitLab 的 CI/CD Pipeline 目前已能順利整合從測試至部署的大多數常見之工具或第三方服務。
• 延續上面三點，透過這些功能與工具的整合，GitLab 提供了一條龍的軟體開發 Workflow，他們將其稱之為 GitLab Workflow。
• GitLab CI/CD Pipeline 的 Job 需透過 GitLab Runner 協助代為執行。
• 續上，同樣的 Runner 可以自行架設，如是使用 gitlab.com 亦可使用大家共用的 Shared Runner。

以上就是幾項關於 GitLab 的基本資訊。

自從 GitLab 的開發團隊開始強化 CI/CD Pipeline 的功能之後，GitLab 越來越受到人們的喜愛。我自己就聽過一些人是因為 GitLab 僅需要設定一個 .gitlab-ci.yml 即可訂製出各式各樣的 Pipeline 以完成自動化測試、自動化部署等工作而深深喜愛它。

GitLab CE（社群版）和 GitLab EE（企業版）該如何選擇？

在繼續這趟 30 天玩轉 GitLab 的旅程之前，還有另一個需要解決的問題，那就是既然 GitLab 分為 CE 與 EE 兩種版本，那究竟我們應該要選用哪一種版本呢？

這裡就直接公布答案嘍！——建議直接選用 GitLab EE（企業版）。

會如此建議是因為 GitLab EE 與 CE 兩者的核心程式碼是相同的，而 GitLab EE 講白話一點它即是 GitLab CE 的威力加強版，因此我們可以在 EE 找到 CE 沒有、最新且方便的各種功能。

當然，不是每個人都願意一開始就付錢採購 GitLab EE 的 license；這也沒關係，因為在沒有註冊 license 的狀況之下，EE 的功能將被縮限至等同於 CE。所以雖然你安裝的是 EE 版，但實際上你等同於是在使用 CE 版。也許哪天你免費版使用的差不多了，願意付費採用 EE 的全套功能時，即可直接就地升級。但如果你一開始安裝的是 CE，當你想要換成 EE 時，還必須要經歷一次從 CE 升級至 EE 的流程。

自行架設 GitLab Server 或使用 gitlab.com？

延續上一個問題，下一步我們要解決問題是——該自行架設 GitLab Server 或使用 gitlab.com？

各家企業的資安政策不同，有些企業限制任何的服務都必須架設在自家的機房並限制於公司內網之內，有些則大力擁抱使用雲端服務。究竟要自行架設 Server 或直接使用雲端上的 gitlab.com，各企業根據自身的考量，有著不同的選擇。

選擇自行架設，首先要考量的是伺服器的成本。GitLab 對於架設環境之需求（Requirements）雖不算高，但也不低。特別是隨著功能日漸強大，其所需之記憶體也有向上攀升的趨勢。我記得當年 GitLab 在 9.0 左右的版本時，記憶體最低需求僅要求 1GB 即可，但現行版本的記憶體需求已攀升到 4GB 了。倘若同時使用 GitLab 的人數會超過 100 人以上，官方甚至建議最好能準備一台 8GB 以上記憶體的主機，才能支撐 GitLab 順暢運作。

此外，除了伺服器實際的成本，軟體的安裝、升級等維護作業，以及伺服器的維運作業這些都需要花費人力，人力成本也是自行架設 GitLab 時，必定需要考量的項目。

反之若是選擇使用 gitlab.com，即可免除伺服器與人力維護的成本，同時軟體的升級也都由 gitlab.com 自行處理，使用者只需要付費即可專心享受 gitlab.com 的服務。（也不用煩惱要用 CE 還是 EE，因為 gitlab.com 就是 EE。）

但就如前述，並非所有的企業都允許員工使用外部的服務，或都信任 gitlab.com 服務的可靠性，畢竟 gitlab.com 也曾經因為人為操作錯誤而出包，導致遺失了客戶存放的資料。

究竟要自行架設或採用 gitlab.com，我個人也沒有一個標準的答案。而就我自身的使用經驗，最初我也是選擇自行架設，但隨著 GitLab 的改版頻繁、使用量提升，漸漸地覺得自行架設消耗的維護與維運成本已超過了最初的期待。而很巧的當時 gitlab.com 正在進行服務與付費等級的調整，於是便趁著當時的機會遷移至 gitlab.com。

因此如果你是小型團隊、企業也沒有針對雲端服務設置了嚴格的資安規定，那在人力與經費有限的情況下，gitlab.com 是一個值得考慮的選項。另外，附帶一提 gitlab.com 目前也已經有台灣代理商，開立發票與中文技術支援這兩件事已不成問題，有興趣的企業大可以放心採購喔！

小結

GitLab 從 2011 年發展至今，已從小巧單一的開源專案發展成一條龍的解決方案。gitlab.com 以目前檯面上消息看來，公司募到的資金充足，亦有足夠的付費客戶，未來的發展是一片看漲令人期待，如果你目前正在挑選適合團隊的 Workflow 或 CI/CD 工具，那不妨給 GitLab 一個機會吧！

第一天的內容就在此告一個段落，明天我們將會介紹如何安裝 GitLab，正式開始進入與實際操作相關的內容。

參考資料

• https://en.wikipedia.org/wiki/GitLab
• https://about.gitlab.com/install/ce-or-ee/
• https://about.gitlab.com/company/history/
• https://docs.gitlab.com/ee/update/README.html#community-to-enterprise-edition
• https://about.gitlab.com/2017/02/10/postmortem-of-database-outage-of-january-31/
• https://about.gitlab.com/resellers/