iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 5
1
DevOps

和艦長一起 30 天玩轉 GitLab系列 第 5

GitLab: 從建立 Group 和 Project 開始

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。

https://ithelp.ithome.com.tw/upload/images/20190918/20120986DNVkbgRtSq.jpg
(Group 的 Visibility Level 設定為 Internal 即代表只有能登入此 GitLab 的 User 才能看見有此 Group 存在。)

接著替這次必須保密到家的重點產品,在該 Internal Group 中分別建立了名為 NCC-1701 的 Private Project,以及名為 SDF-1 的 Internal Project。最核心的產品程式碼必須保密到家,所以為其建立的是 Private Project;而圍繞著產品可能延伸產出的 Packages 則規劃保存在 Internal Project 中,因為也許未來公司其他產品計畫也有機會使用到這些 Packages,必須讓其他團隊的人有機會找到它。

https://ithelp.ithome.com.tw/upload/images/20190918/201209867exVDU2LDg.jpg
(先進入 Group,再點擊 New project 建立隸屬該 Group 的 Project。)

https://ithelp.ithome.com.tw/upload/images/20190918/20120986tvHGm83oRZ.jpg
(在新增 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。

https://ithelp.ithome.com.tw/upload/images/20190918/20120986YeZQv6KCWQ.jpg
(依據不同的職責,設置合適的 Member Permissions,做出適當的權限控管。)

一但加入成為 Group 的 Member,便會自動成為該 Group 底下所有 Project 的 Member,這功能能替我們節省許多設定 Member 的時間。
https://ithelp.ithome.com.tw/upload/images/20190918/20120986bZC4Lthg4h.jpg
(查看 Project 的 Members 即可發現,Project 已直接繼承了 Group 的 Members,並且無法更改。)

雖然我們可以透過 Group 一次搞定自己團隊成員的 Member Permissions,但因為有些職務角色會同時支援數個開發團隊,並非專屬於自己的團隊,同時這些角色也無需加入 Group 之下的每一個 Project。針對此種角色,我們就必須直接在各個 Project 的 settings > Members 逐一將他們設定為 Member。
https://ithelp.ithome.com.tw/upload/images/20190918/20120986B0UXu7XaBZ.jpg
(例如 PM 僅需關注主要產品之 Project,因此不加入 Group,而是依據 Project 逐一設定為 Member。)

小結

今天我們將團隊接下來工作會使用之 GitLab 的 Group、Project 及 Member Permissions 大致搞定。透過完成這項前置作業,後續團隊成員才能擁有足夠的權限來使用 GitLab。雖然這都只是一些 GitLab 基本的操作,如果是一人團隊時可能不太重要(因為一人團隊大概全都開最高權限、都設定為 Private Project 即可);但如果是多人團隊時,這些設定將與後續團隊成員的工作默契、職責歸屬、團隊開發流程與協作方式有關,可就不容小覷了。

今天的內容就先到這裡,明天我們會介紹一下 GitLab 官方提出的 GitLab Workflow,看一下其中有什麼獨到之處!我們明天見~


上一篇
GitLab 的 User 與權限控管
下一篇
初探 GitLab Workflow & GitLab Flow
系列文
和艦長一起 30 天玩轉 GitLab30

尚未有邦友留言

立即登入留言