GitLab 工作流概覽

GitLab 工作流

GitLab 工作流 是在軟體開發過程中，在使用 GitLab 作為代碼託管平台時，可以採取的動作的一個邏輯序列。

GitLab 工作流遵循了 GitLab Flow 策略，這是由一系列由基於 Git 的方法和策略組成的，這些方法為版本的管理，例如分支策略、Git最佳實踐等等提供了保障。

通過 GitLab 工作流，可以很方便的提升團隊的工作效率以及凝聚力。這種提升，從引入一個新的項目開始，一直到發布這個項目，成為一個產品都有所體現。這就是我們所說的「如何通過最快的速度把一個點子在 10 步之內變成一個產品」。

軟體開發階段

一般情況下，軟體開發經過 10 個主要階段；GitLab 為這 10 個階段依次提供了解決方案：

1. IDEA： 每一個從點子開始的項目，通常來源於一次閑聊。在這個階段，GitLab 集成了 Mattermost。
2. ISSUE： 最有效的討論一個點子的方法，就是為這個點子建立一個工單討論。你的團隊和你的合作夥伴可以在 工單追蹤器 issue tracker 中幫助你去提升這個點子
3. PLAN： 一旦討論得到一致的同意，就是開始編碼的時候了。但是等等！首先，我們需要優先考慮組織我們的工作流。對於此，我們可以使用 工單看板 Issue Board 。
4. CODE： 現在，當一切準備就緒，我們可以開始寫代碼了。
5. COMMIT： 當我們為我們的初步成果歡呼的時候，我們就可以在版本控制下，提交代碼到功能分支了。
6. TEST： 通過 GitLab CI，我們可以運行腳本來構建和測試我們的應用。
7. REVIEW： 一旦腳本成功運行，我們測試和構建成功，我們就可以進行 代碼複審 code review 以及批准。
8. STAGING：： 現在是時候將我們的代碼部署到演示環境來檢查一下，看看是否一切就像我們預估的那樣順暢——或者我們可能仍然需要修改。
9. PRODUCTION： 當一切都如預期，就是部署到生產環境的時候了！
10. FEEDBACK： 現在是時候返回去看我們項目中需要提升的部分了。我們使用 周期分析 Cycle Analytics 來對當前項目中關鍵的部分進行的反饋。

簡單瀏覽這些步驟，我們可以發現，提供強大的工具來支持這些步驟是十分重要的。在接下來的部分，我們為 GitLab 的可用工具提供一個簡單的概覽。

GitLab 工單追蹤器

GitLab 有一個強大的工單追溯系統，在使用過程中，允許你和你的團隊，以及你的合作者分享和討論建議。

工單是 GitLab 工作流的第一個重要重要特性。以工單的討論為開始； 跟蹤新點子的改變是一個最好的方式。

這十分有利於：

• 討論點子
• 提交功能建議
• 提問題
• 提交錯誤和故障
• 獲取支持
• 精細化新代碼的引入

每一個在 GitLab 上部署的項目都有一個工單追蹤器。找到你的項目中的 Issues > New issue 來創建一個新的工單。建立一個標題來總結要被討論的主題，並且使用 Markdown 來形容它。看看下面的「專業技巧」來加強你的工單描述。

GitLab 工單追蹤器提供了一個額外的實用功能，使得步驟變得更佳易於管理和考慮。下面的部分仔細描述了它。

秘密工單

無論何時，如果你僅僅想要在團隊中討論這個工單，你可以使該工單成為秘密的。即使你的項目是公開的，你的工單也會被保密起來。當一個不是本項目成員的人，就算是 [報告人級別][01]，想要訪問工單的地址時，瀏覽器也會返回一個 404 錯誤。

截止日期

每一個工單允許你填寫一個截止日期。有些團隊工作時間表安排緊湊，以某種方式去設置一個截止日期來解決問題，是有必要的。這些都可以通過截止日期這一功能實現。

當你對一個多任務項目有截止日期的時候——比如說，一個新的發布活動、項目的啟動，或者按階段追蹤任務——你可以使用里程碑。

受託者

要讓某人處理某個工單，可以將其分配給他。你可以任意修改被分配者，直到滿足你的需求。這個功能的想法是，一個受託者本身對這個工單負責，直到其將這個工單重新賦予其他人。

這也可以用於按受託者篩選工單。

標籤

GitLab 標籤也是 GitLab 流的一個重要組成部分。你可以使用它們來分類你的工單，在工作流中定位，以及通過優先順序標籤來安裝優先順序組織它們。

標籤使得你與GitLab 工單看板協同工作，加快工程進度以及組織你的工作流。

新功能： 你可以創建組標籤。它可以使得在每一個項目組中使用相同的標籤。

工單權重

你可以添加個工單權重使得一個工單重要性表現的更為清晰。01 - 03 表示工單不是特別重要，07 - 09 表示十分重要，04 - 06 表示程度適中。此外，你可以與你的團隊自行定義工單重要性的指標。

註：該功能僅可用於 GitLab 企業版和 GitLab.com 上。

GitLab 工單看板

在項目中，GitLab 工單看板是一個用於計劃以及組織你的工單，使之符合你的項目工作流的工具。

看板包含了與其相關的相應標籤，每一個列表包含了相關的被標記的工單，並且以卡片的形式展示出來。

這些卡片可以在列表之間移動，被移動的卡片，其標籤將會依據你移動的位置相應更新到列表上。

新功能： 你也可以通過點擊列表上方的「+」按鈕在看板右邊創建工單。當你這麼做的時候，這個工單將會自動添加與列表相關的標籤。

新功能： 我們最近推出了 每一個 GitLab 項目擁有多個工單看板的功能（僅存在於 GitLab 企業版）；這是為不同的工作流組織你的工單的好方法。

通過 GitLab 進行代碼複審

在工單追蹤器中，討論了新的提議之後，就是在代碼上做工作的時候了。你在本地書寫代碼，一旦你完成了你的第一個版本，提交你的代碼並且推送到你的 GitLab 倉庫。你基於 Git 的管理策略可以在 GitLab 流中被提升。

第一次提交

在你的第一次提交信息中，你可以添加涉及到工單號在其中。通過這樣做你可以將兩個階段的開發工作流鏈接起來：工單本身以及關於這個工單的第一次提交。

這樣做，如果你提交的代碼和工單屬於同一個項目，你可以簡單的添加 #xxx 到提交信息中（LCTT 譯註：git commit message），xxx是一個工單號。如果它們不在一個項目中，你可以添加整個工單的整個URL（https://gitlab.com/<username>/<projectname>/issues/<xxx>）。

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

或者

git commit -m "this is my commit message. Related to https://gitlab.com/<username>/<projectname>/issues/<xxx>"

當然，你也可以替換 gitlab.com，以你自己的 GitLab 實例來替換這個 URL。

註： 鏈接工單和你的第一次提交是為了通過 GitLab 周期分析追蹤你的進展。這將會衡量計劃執行該工單所採取的時間，即創建工單與第一次提交的間隔時間。

合併請求

一旦將你的改動提交到功能分支，GitLab 將識別該修改，並且建議你提交一次 合併請求 Merge Request （MR）。

每一次 MR 都會有一個標題（這個標題總結了這次的改動）並且一個用 Markdown 書寫的描述。在描述中，你可以簡單的描述該 MR 做了什麼，提及任何工單以及 MR（在它們之間創建聯繫），並且，你也可以添加個關閉工單模式，當該 MR 被合併的時候，相關聯的工單就會被關閉。

例如:

## 增加一個新頁面

這個 MR 將會為這個項目創建一個包含該 app 概覽的 `readme.md`。

Closes #xxx and https://gitlab.com/<username>/<projectname>/issues/<xxx>

預覽：

![預覽新頁面](#image-url)

cc/ @Mary @Jane @John

當你創建一個如上的帶有描述的 MR，它將會：

• 當合併時，關閉包括工單 #xxx 以及 https://gitlab.com/<username>/<projectname>/issues/<xxx>
• 展示一張圖片
• 通過郵件提醒用戶 @Mary、@Jane，以及給 @John

你可以分配這個 MR 給你自己，直到你完成你的工作，然後把它分配給其他人來做一次代碼複審。如果有必要的話，這個 MR 可以被重新分配多次，直到你覆蓋你所需要的所有複審。

它也可以被標記，並且添加一個里程碑來促進管理。

當你從圖形界面而不是命令行添加或者修改一個文件並且提交一個新的分支時，也很容易創建一個新的 MR，僅僅需要標記一下複選框，「以這些改變開始一個新的合併請求」，然後，一旦你提交你的改動，GitLab 將會自動創建一個新的 MR。

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

新功能： 我們已經開發了審查應用，這是一個可以讓你部署你的應用到一個動態的環境中的新功能，在此你可以按分支名字、每個合併請求來預覽改變。參看這裡的可用示例。

WIP MR

WIP MR 含義是 在工作過程中的合併請求，是一個我們在 GitLab 中避免 MR 在準備就緒前被合併的技術。只需要添加 WIP: 在 MR 的標題開頭，它將不會被合併，除非你把 WIP: 刪除。

當你改動已經準備好被合併，編輯工單來手動刪除 WIP: ，或者使用就像如下 MR 描述下方的快捷方式。

新功能： WIP 模式可以通過斜線命令 /wip 快速添加到合併請求中。只需要在評論或者 MR 描述中輸入它並提交即可。

複審

一旦你創建一個合併請求，就是你開始從你的團隊以及合作方收取反饋的時候了。使用圖形界面中的差異比較功能，你可以簡單的添加行內注釋，以及回復或者解決它們。

你也可以通過點擊行號獲取每一行代碼的鏈接。

在圖形界面中可以看到提交歷史，通過提交歷史，你可以追蹤文件的每一次改變。你可以以行內差異或左右對比的方式瀏覽它們。

新功能： 如果你遇到合併衝突，可以快速地通過圖形界面來解決，或者依據你的需要修改文件來修復衝突。

構建、測試以及發布

GitLab CI 是一個強大的內建工具，其作用是持續集成、持續發布以及持續分發，它可以按照你希望的運行一些腳本。它的可能性是無止盡的：你可以把它看做是自己運行的命令行。

它完全是通過一個名為 .gitlab-ci.yml 的 YAML 文件設置的，其放置在你的項目倉庫中。使用 Web 界面簡單的添加一個文件，命名為 .gitlab-ci.yml 來觸發一個下拉菜單，為不同的應用選擇各種 CI 模版。

Koding

Use GitLab's Koding integration to run your entire development environment in the cloud. This means that you can check out a project or just a merge request in a full-fledged IDE with the press of a button.

可以使用 GitLab 的 Koding 集成功能在雲端運行你的整個雲端開發環境。這意味著你可以輕輕一鍵即可在一個完整的 IDE 中檢出以個項目，或者合併一個請求。

使用案例

GitLab CI 的使用案例：

• 用它來構建任何靜態網站生成器，並且通過 GitLab Pages 發布你的網站。
• 用它來發布你的網站 到 staging 以及 production 環境。
• 用它來構建一個 iOS 應用。
• 用它來構建和發布你的 Docker 鏡像到 GitLab 容器註冊庫。

我們已經準備一大堆 GitLab CI 樣例工程作為您的指南。看看它們吧！

反饋：周期分析

當你遵循 GitLab 工作流進行工作，你的團隊從點子到產品，在每一個過程的關鍵部分，你將會在下列時間獲得一個 GitLab 周期分析的反饋：

• Issue： 從創建一個工單，到分配這個工單給一個里程碑或者添加工單到你的工單看板的時間。
• Plan： 從給工單分配一個里程碑或者把它添加到工單看板，到推送第一次提交的時間。
• Code： 從第一次提交到提出該合併請求的時間。
• Test： CI 為了相關合併請求而運行整個過程的時間。
• Review： 從創建一個合併請求到合併它的時間。
• Staging： 從合併到發布成為產品的時間。
• Production（Total）： 從創建工單到把代碼發布成產品的時間。

加強

工單以及合併請求模版

工單以及合併請求模版允許你為你的項目去定義一個特定內容的工單模版和合併請求的描述欄位。

你可以以 Markdown 形式書寫它們，並且把它們加入倉庫的默認分支。當創建工單或者合併請求時，可以通過下拉菜單訪問它們。

它們節省了您在描述工單和合併請求的時間，並標準化了需要持續跟蹤的重要信息。它確保了你需要的一切都在你的掌控之中。

你可以創建許多模版，用於不同的用途。例如，你可以有一個提供功能建議的工單模版，或者一個 bug 彙報的工單模版。在 GitLab CE project 中尋找真實的例子吧！

里程碑

里程碑 是 GitLab 中基於共同的目標、詳細的日期追蹤你隊伍工作的最好工具。

不同情況下的目的是不同的，但是大致是相同的：你有為了達到特定的目標的工單的集合以及正在編碼的合併請求。

這個目標基本上可以是任何東西——用來結合團隊的工作，在一個截止日期前完成一些事情。例如，發布一個新的版本，啟動一個新的產品，在某個日期前完成，或者按季度收尾一些項目。

專業技巧

工單和 MR

• 在工單和 MR 的描述中:
  • 輸入 # 來觸發一個已有工單的下拉列表
  • 輸入 ! 來觸發一個已有 MR 的下拉列表
  • 輸入 / 來觸發斜線命令
  • 輸入 : 來出發 emoji 表情 (也支持行中評論)
• 通過按鈕「附加文件」來添加圖片（jpg、png、gif) 和視頻到行內評論
• 通過 GitLab Webhooks 自動應用標籤
• 構成引用: 使用語法 >>> 來開始或者結束一個引用

>>>
Quoted text

Another paragraph
>>>

• 創建任務列表：

- [ ] Task 1
- [ ] Task 2
- [ ] Task 3

訂閱

你是否發現你有一個工單或者 MR 想要追蹤？展開你的右邊的導航，點擊訂閱，你就可以在隨時收到一個評論的提醒。要是你想要一次訂閱多個工單和 MR？使用批量訂閱。

添加代辦

除了一直留意工單和 MR，如果你想要對它預先做點什麼，或者不管什麼時候你想要在 GitLab 代辦列表中添加點什麼，點擊你右邊的導航，並且點擊添加代辦。

尋找你的工單和 MR

當你尋找一個在很久以前由你開啟的工單或 MR——它們可能數以十計、百計、甚至千計——所以你很難找到它們。打開你左邊的導航，並且點擊工單或者合併請求，你就會看到那些分配給你的。同時，在那裡或者任何工單追蹤器里，你可以通過作者、分配者、里程碑、標籤以及重要性來過濾工單，也可以通過搜索所有不同狀態的工單，例如開啟的、合併的，關閉的等等。

移動工單

一個工單在一個錯誤的項目中結束了？不用擔心，點擊Edit，然後移動工單到正確的項目。

代碼片段

你經常在不同的項目以及文件中使用一些相同的代碼段和模版嗎？創建一個代碼段並且使它在你需要的時候可用。打開左邊導航欄，點擊Snipptes。所有你的片段都會在那裡。你可以把它們設置成公開的，內部的（僅為 GitLab 註冊用戶提供），或者私有的。

GitLab 工作流用戶案例概要

作為總結，讓我們把所有東西聚在一起理順一下。不必擔心，這十分簡單。

讓我們假設：你工作於一個專註於軟體開發的公司。你創建了一個新的工單，這個工單是為了開發一個新功能，實施於你的一個應用中。

標籤策略

為了這個應用，你已經創建了幾個標籤，「討論」、「後端」、「前端」、「正在進行」、「展示」、「就緒」、「文檔」、「營銷」以及「產品」。所有都已經在工單看板有它們自己的列表。你的當前的工單已經有了標籤「討論」。

在工單追蹤器中的討論達成一致之後，你的後端團隊開始在工單上工作，所以他們把這個工單的標籤從「討論」移動到「後端」。第一個開發者開始寫代碼，並且把這個工單分配給自己，增加標籤「正在進行」。

編碼 & 提交

在他的第一次提交的信息中，他提及了他的工單編號。在工作後，他把他的提交推送到一個功能分支，並且創建一個新的合併請求，在 MR 描述中，包含工單關閉模式。他的團隊複審了他的代碼並且保證所有的測試和建立都已經通過。

使用工單看板

一旦後端團隊完成了他們的工作，他們就刪除「正在進行」標籤，並且把工單從「後端」移動到「前端」看板。所以，前端團隊接到通知，這個工單已經為他們準備好了。

發布到演示

當一個前端開發者開始在該工單上工作，他（她）增加一個標籤「正在進行」，並且把這個工單重新分配給自己。當工作完成，該實現將會被發布到一個演示環境。標籤「正在進行」就會被刪除，然後在工單看板里，工單卡被移動到「演示」列表中。

團隊合作

最後，當新功能成功實現，你的團隊把它移動到「就緒」列表。

然後，就是你的技術文檔編寫團隊的時間了，他們為新功能書寫文檔。一旦某個人完成書寫，他添加標籤「文檔」。同時，你的市場團隊開始啟動並推薦該功能，所以某個人添加「市場」。當技術文檔書寫完畢，書寫者刪除標籤「文檔」。一旦市場團隊完成他們的工作，他們將工單從「市場」移動到「生產」。

部署到生產環境

最後，你將會成為那個為新版本負責的人，合併「合併請求」並且將新功能部署到生產環境，然後工單的狀態轉變為關閉。

反饋

通過周期分析，你和你的團隊節省了如何從點子到產品的時間，並且開啟另一個工單，來討論如何將這個過程進一步提升。

總結

GitLab 工作流通過一個單一平台幫助你的團隊加速從點子到生產的改變：

• 它是有效的：因為你可以獲取你想要的結果
• 它是高效的：因為你可以用最小的努力和成本達到最大的生產力
• 它是高產的：因為你可以非常有效的計劃和行動
• 它是簡單的：因為你不需要安裝不同的工具去完成你的目的，僅僅需要 GitLab
• 它是快速的：因為你不需要在多個平台間跳轉來完成你的工作

每一個月的 22 號都會有一個新的 GitLab 版本釋出，讓它在集成軟體開發解決方案上變得越來越好，讓團隊可以在一個單一的、唯一的界面下一起工作。

在 GitLab，每個人都可以奉獻！多虧了我們強大的社區，我們獲得了我們想要的。並且多虧了他們，我們才能一直為你提供更好的產品。

還有什麼問題和反饋嗎？請留言，或者在推特上@我們@GitLab!

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

作者：Marcia Ramos 譯者：svtter 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive