Gitlab概覽

Gitlab是開源的基於Git的倉庫管理系統，也可以管理軟體開發的整個生命周期，是項目管理和代碼託管平臺，支撐著整個DevOps的生命周期。Gitlab很容易選為GitHub，作為公司私有庫管理的工具。我們可以用Gitlab Workflow來協同整個團隊的軟體開發管理過程。

軟體開發階段

gitlab軟體開發階段

Gitlab工作流將軟體開發定義為10個階段，並提供相應的解決方案，幫助團隊高效協作，完成項目開發。

Gitlab flow

區別於SVN等版本控制系統，基於Git的版本管理對於創建分支和合併變得更加容易，也方便項目的管理。

gitlab工作流

利用工單追蹤，將功能特徵驅動開發和功能特徵分支有機結合在一起。受保護的分支對於權限較低開發者等角色需要通過發起合併請求，覆核評審通過後最終才能合併到保護分支。GitLab flow是GitLab官方推薦的分支管理策略。我們可以在原則上約定：分支分為永久分支和臨時分支，都是在master分支以外建立。永久分支不會被刪除，包括主分支master，準生產分支pre-production，生產分支production。臨時分支分為Feature特徵分支和Fix修復分支，在開發完成會被刪除。一種簡單的方案，通常可以基於最新的master主分支，創建特徵分支，進行特徵開發，最後合併請求到master分支。

gitlab特徵分支

只有一個master主分支，這樣的好處在於，可以代碼及時合併，可以是本地代碼庫存量最小，也可以更快的持續交付。當然，與此同時，部署、環境、集成等相關問題也沒得到很好的解決。

對於每一次分支合併，我們總是期望可以部署一個穩定的版本。我們可以考慮多環境分支的情況。

gitlab多環境分支

Gitlab flow 的最大原則叫做"上遊優先"（upsteam first）。代碼的變化，必須由"上遊"向"下遊"發展。Feature和Fix是master的"上遊"，master是pre-production的上遊，pre-production是production的"上遊"。比如，生產環境出現了bug 或者要開發新的feature，這時就要建一個臨時Hotfix或Feature分支，開發完成把它合併到master，確認沒有問題，再cherry-pick到pre-production，這一步也沒有問題，才進入production。Feature和Fix在開發人員在開發環境部署測試，master在測試環境中部署測試，pre-production在演示環境中部署測試，production在生產環境發布，一條流水線下來，可以持續完成項目的部署交付。

此外，我們可以有多穩定版本的分支策略，用於將軟體發布給外界。

gitlab-release分支

版本發布適用於APP、小程序等有版本規劃的項目。穩定分支以master為起點，並儘可能晚地創建。通過儘可能晚的分支，可以最大程度地減少將錯誤修正應用於多個分支的時間。在master上打出穩定的分支版本。如果穩定分支發行後，出現bug，可以先將錯誤修復到master，然後cherry-picked到穩定分支，我們可以通過設置Tag來提高補丁版本，可以維護一個穩定分支專門指向最新版本發布的分支提交。

此外，我們可以對分支名稱做個約定，在Gitlab上 基於issue創建的分支默認是issue編號+issue標題等等。

Issue

GitLab 有一個強大的工單追溯系統，在使用過程中，允許你和你的團隊，以及你的合作者分享和討論建議。所有的開發工作都應該以工單任務為導向。

gitlab-issue

我們可以填寫是否私密、受託人、截止日期、標籤 、裡程碑等信息，利用這些信息可以更加方便地組織活動和安排優先級。

Labels

GitLab 標籤也是Gitlab flow的重要組成部分，可以對issue工單進行分類和定位。也可以通過定義優先級標籤組織它們。通常和Boards一起，來組織計劃和工作流程。

gitlab-label

我們可以根據需要設計一些常用標籤，如待辦類，Bug類，功能改進類等進行定位、統計和跟蹤。

Boards

Gitlab 工單面板是一個用於計劃以及組織工單，使之符合項目工作流的工具。Boards包含了與其相關的對應標籤，每一個列表包含了相關的被標記的issue工單，並且以卡片的形式展示出來。這些issue卡片可以在列表之間推拽移動，被移動的卡片，其標籤將會依據你移動的位置更新到相應列表上。

gitlab-boards

Milestones

Milestones 是GitLab 中基於共同目標、時間進度追蹤團隊工作的最好工具。它定義了目標階段對應的工單集合和合併請求。通常是團隊協作在截止日期完成某個目標。例如，發布一個新的版本，啟動一個新的產品，在某個日期前完成，或者按季度收尾一些項目。

gitlab-milestones

Merge Request

我們可以根據issue創建branch和發起Merge Requests(MR)合併到目標分支。

gitlab-MR

開發者檢出特徵分支開發，提交後並推送到遠程。功能分支和修復分支合併進master分支，必須通過Merge Requests。審核員可以對這些提交和變化進行評審，可以反覆這個過程，直到符合代碼規範，才合併到目標分支。

gitlab-branch-checkout

master分支應該受到保護，不是每個人都可以直接修改這個分支，以及擁有審批 Merge Request的權力。

gitlab-protected-branches

上圖展示了保護分支的權限設置，規定了哪些角色具有Branch的MR和push的權限。否則，推送無權限的分支時可能會出現以下錯誤：

you are not allowed to push code to protected branches on this project

每一次 MR 都會有一個標題（這個標題總結了這次的改動）並且一個用 書寫的描述。在描述中，你可以簡單的描述該 MR 做了什麼，涉及的任何工單和 MR（在它們之間創建聯繫），並且，你也可以添加個，當該MR 被合併的時候，相關聯的工單就會自動被關閉。在描述裡添加 Closes #xxx，xxx為對應的issue編號。Merge成功後，自動關閉工單。

gitlab-markdown

有權限角色在Merge RequestMerge 前，注意下Merge的內容，評審通過後，最好能確保每一次Merge後對應Master分支都是穩定的。

gitlab-merge-request

WIP MR

WIP (Work in Process) MR,避免 MR 在準備就緒前被合併。只需要添加 WIP: 在 MR 的標題開頭，它將不會被合併，除非你把 WIP: 刪除。當你改動已經準備好被合併，編輯工單來手動刪除 WIP: 。或者使用快捷方式，只需要在評論或者 MR 描述中輸入斜線命令/wip並提交即可快速添加到合併請求中。

gitlab-wip

Code Review

一旦你創建一個合併請求，審核方收到反饋，就可以決定是否合併這個請求了。審核者可以進行差異比較，回復或者解決它們。在圖形界面中可以看到提交歷史，通過提交歷史，你可以追蹤文件的每一次改變。你可以以行內差異或左右對比的方式瀏覽它們,甚至評論他們。

gitlab-codeview

如果有合併衝突，甚至可以在線編輯解決。

Memebers

項目擁有者和維護者需要添加協作的團隊成員，進行項目協同，可以選擇已註冊gitlab的有效成員進行邀請。

gitlab-members

受邀人會受到電子郵件，同意後就可以加入團隊了。低權限角色只能開發，甚至只能瀏覽，無權限維護。

CI/CD

是構建項目持續集成、持續部署和持續交付的有效工具。首先需要在項目根目錄下創建文件.gitlab-ci.yml。

gitlab-ci/cd

例如，我們可以在項目中每一次Merge Request，都可以觸發pipeline 去構建、測試和部署。而具體的構建規則可以根據編寫不同的.gitlab-ci.yaml腳本實現。CI/CD pipelines的運行離不開Gitlab Runner。所以，還需要安裝GitLab Runner，它可以在任何地方（能ping通Gitlab）運行，也可以是以Shell、docker、kubernetes等不同的形式運行。GitLab Runner向Gitlab註冊，需要Gitlab授權。註冊成功後，GitLab Runners負責從Gitlab拉取代碼進行構建、測試和部署。區別於Jenkins，Gitlab-CI更加適合DevOps人員，開發與運維是同一個人，非常適合敏捷開發。Jenkins通過Hook可以使編譯服務和代碼倉庫分離，耦合度低，適合多角色團隊，職責分明。將另有篇幅概述，這一塊暫不贅述。

周期分析

我們可以通過周期分析，可以查看各個階段的統計，及時反饋項目的進展和改進項目的不足之處。

gitlab-analytics

Markdown Tips

在Issue 或 Merge Request 等對應的markdown描述或者git commit -m ""注釋信息中，可以添加特殊標識來實現一些特性。可以看下簡單的例子：

## 增加一個新頁面這個 MR 將會為這個項目創建一個包含該 app 概覽的 `readme.md`。Closes #1,#2 and https://gitlab.wenqy.com/group/project/issues/<8>related to #3:smile:/cc @wenqy @all

上面是MR的一段描述。合併時，會關閉編號為1,2的issue工單，以及url指向的項目工單。這還做了一個編號為3的issue工單關聯，不會關閉。並郵件通知用戶。還支持emoji表情。

添加到你的 MR 以便可以使用 【GitLab周期分析】追蹤你的項目進展，是十分重要的。它將會追蹤"CODE"階段，衡量第一次提交及創建一個相關的合併請求所間隔的時間。

第一次提交

第一次提交時添加一個關聯的Issue編號，利用Ref #關聯

git commit -m "this is my commit message. Ref #xxx"

或者使用全稱Related to關聯

git commit -m "this is my commit message. Related to https://gitlab.com///issues/"

連結第一次提交與Issue，將有助於【GitLab周期分析】跟蹤工作流程，它將度量計劃該Issue的實現所用的時間，即從創建Issue到進行第一次提交之間的時間。

任務列表

在描述裡添加 - [] 子任務，劃分子任務

- [x] Completed task - [ ] Incomplete task - [ ] Sub-task 1 - [x] Sub-task 2 - [ ] Sub-task

描述裡面體現子任務的列表

gitlab-tasklist

此外，markdown描述裡輸入#，觸發已有issue下拉；輸入！，觸發已有MR下拉；輸入/，觸發命令；輸入:，觸發emoji

在CI中還可以在git commit 注釋裡添加[ci skip]跳過CI等等。

此外，還可以對Issue和Merge Request等描述定義描述模板，規範描述。

Gitlab還有wiki和代碼片段等知識庫的管理和分享功能，方便團隊規範行為。

總結

Gitlab開源免費，可以自建gitlab。它清晰且直觀地劃分了軟體開發管理的各個階段，可以無縫銜接過渡到每個階段。它能預測和控制項目的生命周期，整個平臺很容易上手和使用，以自己的工作流管理項目的整個生命周期非常方便，輕量而敏捷，甚至可以說是一體化管理，為敏捷而生，是一個值得推薦的協同開發項目管理工具。

參考

https://about.gitlab.com/blog/2016/10/25/gitlab-workflow-an-overview/

https://about.gitlab.com/blog/2014/09/29/gitlab-flow/

https://docs.gitlab.com/ee/topics/gitlab_flow.html

https://docs.gitlab.com/ee/user/markdown.html

https://gitlab.com/gitlab-org/omnibus-gitlab/-/labels