GitLab: 從建立 Group 和 Project 開始
本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。
本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。 鐵人賽原文網址：https://ithelp.ithome.com.tw/articles/10216864）
YA！本系列文已經進入第 5 天！在艦長拖了4 天的時間之後，今天我們終於要進到 Project 了！說是這麼說，但其實今天也還不會深入 Project 啦～（揍飛）
背景說明
從今天開始，後續的文章我們會試著模擬一個開發團隊的運作，藉此了解當一個團隊打算使用 GitLab 時，會逐一遇到哪些問題，並且需要使用 GitLab 的哪些功能，所以讓我們先來說明一下故事背景，大家可以想像一下這個情境。
伴隨著公司的發展計畫，從今天開始公司將要開展一項全新的產品，為此公司籌組了一個全新的開發團隊，計畫從零開始達成這項產品開發任務。最初開發團隊將由以下的成員組成：
- Boss
- PM
- Dev Leader
- Developer
- QA
依據這樣的故事背景，現在這個團隊要在老闆的一聲令下開始運作了！
從建立 Group 和 Project 開始
首先，團隊才剛組成，為了讓團隊能順利的開展工作，擁有 GitLab 較高 User 權限的 Dev Leader 需要負責為團隊建立所需之 GitLab Group 與 Project。
第一步我們先以 Unicorn 為名，建立第一層的 Internal Group，確保本產品所有的 Project 都隸屬於此 Internal Group，限制只有公司之內的 User 才能看見此產品隸屬的 Group 與 Project。
（Group 的 Visibility Level 設定為 Internal 即代表只有能登入此 GitLab 的 User 才能看見有此 Group 存在。）
接著替這次必須保密到家的重點產品，在該 Internal Group 中分別建立了名為 NCC-1701 的 Private Project，以及名為 SDF-1 的 Internal Project。最核心的產品程式碼必須保密到家，所以為其建立的是 Private Project；而圍繞著產品可能延伸產出的 Packages 則規劃保存在 Internal Project 中，因為也許未來公司其他產品計畫也有機會使用到這些 Packages，必須讓其他團隊的人有機會找到它。
（先進入 Group，再點擊 New project 建立隸屬該 Group 的 Project。）
（在新增 Project 時，可以選擇該 Project 隸屬哪個 Group 或 User，不過一般的 User 只能建立自己的 Project，只有較高權限的 User，才會如上圖有多個選項可以選擇。如果有不想被無關者發現的 Project，務必要將 Visibility Level 設定為 Private。）
為團隊成員設定合乎職責的 Member Permissions
Group 與 Project 建立完畢後，緊接著要將團隊所有的成員加入成為 Group 的 Member，並根據職責給予不同的 Member Permissions。
- Boss 基本上只出一張嘴，為了避免他沒事亂按亂改，因此先分配為
Member Permissions為 Guest。（老闆：桌上那個發射核彈的紅色按鈕可以按嗎？） - Dev Leader 因為是 Group 的建立者，因此
Member Permissions為 Owner，擁有 Group 的最高權限，可以管理 Group 旗下的 Members、Projects 及各種 Settings。 - Senior Developer 是資深的開發者，也會負責 Code Review 與 git 分支管控的工作，因此
Member Permissions為 Maintainer。 - Developer 是一般的開發者，只要專心寫程式即可，因此
Member Permissions為 Developer，負責 Commit Code 與送出 Merge Request 給 Senior Developer 進行 Code Review。 - Tester 是測試人員，負責程式的測試與驗收，無需提交 Commit 或發送 Merge Request，但需要能夠回報 Issue 的權限，因此
Member Permissions設定為 Reporter。
（依據不同的職責，設置合適的 Member Permissions，做出適當的權限控管。）
一但加入成為 Group 的 Member，便會自動成為該 Group 底下所有 Project 的 Member，這功能能替我們節省許多設定 Member 的時間。
（查看 Project 的 Members 即可發現，Project 已直接繼承了 Group 的 Members，並且無法更改。）
雖然我們可以透過 Group 一次搞定自己團隊成員的 Member Permissions，但因為有些職務角色會同時支援數個開發團隊，並非專屬於自己的團隊，同時這些角色也無需加入 Group 之下的每一個 Project。針對此種角色，我們就必須直接在各個 Project 的 settings > Members 逐一將他們設定為 Member。
（例如 PM 僅需關注主要產品之 Project，因此不加入 Group，而是依據 Project 逐一設定為 Member。）
小結
今天我們將團隊接下來工作會使用之 GitLab 的 Group、Project 及 Member Permissions 大致搞定。透過完成這項前置作業，後續團隊成員才能擁有足夠的權限來使用 GitLab。雖然這都只是一些 GitLab 基本的操作，如果是一人團隊時可能不太重要（因為一人團隊大概全都開最高權限、都設定為 Private Project 即可）；但如果是多人團隊時，這些設定將與後續團隊成員的工作默契、職責歸屬、團隊開發流程與協作方式有關，可就不容小覷了。
今天的內容就先到這裡，明天我們會介紹一下 GitLab 官方提出的 GitLab Workflow，看一下其中有什麼獨到之處！我們明天見～
【新增補充】GitLab 原廠已經捨棄 GitLab Workflow，改為倡議 DevOps Lifecycle，至於 GitLab Workflow 則被原廠拿去當作 VS Code extension 的名稱。