佛羅倫薩 - 聖母百花聖殿（圖）
前言
GitLab 和 Jira 是平時開發過程中使用非常高頻的代碼管理系統（開發人員）和項目管理系統（項目管理），通過兩套系統的協作完成平常大多數的功能開發，但是兩套系統在沒有集成情況下是完全兩套獨立的系統，不僅信息沒有互通，而且開發人員需要反復的登陸兩套不同的系統，進行一些重復的操作才能保證功能流的正常流轉，不僅效率低下，浪費時間和人力，而且因為人本身的不可靠屬性，所以導致狀態的流轉並不能非常的及時和准確，這種重復和機械的動作恰恰是自動化所擅長的地方，今天我介紹一下如何集成 GitLab 和 Jira 的工作流，提高團隊的開發體驗，提升大家的開發效率，可以把騰出的精力和時間都放在更有價值的事情上
- GitLab 如何開啟 JIRA 的入口？
- GitLab 如何打通 JIRA 的信息流？
- GitLab 如何自動化 JIRA 的工作流（workflow）？
- GitLab 如何批量觸發 JIRA 的工作量 ？
GitLab 如何開啟 JIRA 的入口？
GitLab 需要一個專屬的 JIRA 賬號，並且擁有相應的權限，用於在 JIRA issues 添加注釋和操作系統，具體如何在 JIRA 中創建和配置賬號這里就不介紹了，不熟悉的小伙伴可以直接看官方文檔 Creating a username and password for Jira Server 的介紹
然后進入 GitLab 選擇對應的 Project -> Setting ->Integrations -> Jira
GitLab JIRA 的配置頁面：
配置也非常簡單，這里我簡要說明一下：
- Web url ：你們公司的 JIRA 訪問地址
- Jira API URL：使用 JIRA cloud 填寫的 api 地址，可選項，沒有使用為空即可
- username or email：在上面創建 JIRA 的賬號
- password：在上面創建 JIRA 的密碼
- Transition id(s)：這里比較關鍵，是自動化工作流的核心，有以下幾點注意事項：
- 首先這里是指 GitLab commit or merge 動作關鍵字觸發對應的 JIRA workflow ID（狀態 ID，多個狀態使用 , or ; 號分割）
- 限制：workflow id 必須是連續的狀態，如果是有中間狀態則會跳轉失敗
- 只會對 JIRA status: resolution = unresolved 的 issues 生效，就是說 GitLab 不會去觸發 issue 狀態為 close 或者為 done 的工作流
配置成功后會顯示 JIRA active
並且在 project 主菜單的左側增加 JIRA 的快捷入口，點擊快捷跳轉到配置好的 JIRA web url，如圖：
Setting -> Integrations 顯示：
到這里第一步，配置就完成了
GitLab 如何打通 JIRA 的信息流？
完成第一步配置，后續的信息流就簡單的多了，但是功能強大，讓使用在 GitLab JIRA 之間無縫切換，行雲流水，具體有以下幾種玩法：
首先是 JIRA issue 的映射，只要是 push 到遠端倉庫的 commit 會自動關聯到 JIRA 對應的 issue 頁面，點擊即可訪問，在項目下的 commit history 可以看到：
點擊 TEST-220 則可以直接跳轉到對應的。JIRA 詳情：
在解決該 issue 的過程中，所有的 commit log 也會被自動關聯到 JIRA issue 的注釋中，在 JIRA 系統中形成問題的解決歷史和思路，方便復盤和回顧：
JIRA issue 的自動注釋的格式規范：
USER mentioned this issue in RESOURCE_NAME of [PROJECT_NAME|LINK_TO_COMMENT]:
ENTITY_TITLE
更方便的是 issue 下面的自動 commit 注釋，也是訪問 GitLab 的超鏈接，點擊進去可以查看到當次 commit 的修改詳情，例如我們點擊這個 Commit - TEST-220 resolver a problem ... ，可以看到具體的代碼改動項：
要享受以上的所有收益，只需要遵循一條簡單的 commit 規范，既在項目配置 JIRA active 的情況下，在 commit 中代碼 JIRA issue 編號即可，而且 commit 信息一旦被推送到 GitLab 遠端分支，就會馬上被在對應 JIRA issue 下面增加 commit. 注釋，可以說使用起來非常的方便，示例的 commit 如下：
git commit -am 'TEST-220 resolver a problem'
GitLab 如何自動化 JIRA 的工作流（workflow）？
這里應該算是集成中最實用，也比較復雜的功能，通過 GitLab 的 commit or merge 動作改變 JIRA issue 狀態（根據我們上面配置的 transition ID 來流轉），自動觸發狀態流轉的關鍵字有以下 3 個：
- Resolvers Issue-1
- Closes Issue-1
- Fixed Issue-1
當然觸發工作流的動作也是有限制的，我們先看官方文檔的描述：
Notes:
Only commits and merges into the project’s default branch (usually master) will close an issue in Jira. You can change your projects default branch under project settings.
The Jira issue will not be transitioned if it has a resolution.
我在這里簡單轉述一下：
- 只有默認分支（master 可以在 GitLab -> Settings 中配置）的 commit and merge 會觸發關閉 JIRA issue
- 已有解決方案的 JIRA issue 則不會發生狀態流轉（就是我之前說的：只會對 JIRA.issue.status.resolution = unresolved 的 issues 生效）
我們目前的痛點是：
每次需求上線后，都開發人員在 JIRA 里面點 On Line 來確定功能已經發布，但是此時 On Line 狀態的需求通常不掛在開發人員身上，開發人員每次需求上線后需要做以下操作：
- 登陸 Jira 系統，輸入賬號密碼
- 找到項目，通過需求編號，找到對應已經上線的需求
- 在狀態項點擊 On Line 按鈕，改變 JIRA issue 的狀態
以上操作雖然不復雜，但是每一個需求上線都需要做一次重復的操作，有時候版本功能多，所有任務都需要逐個搜索出來手動更改狀態，不僅效率不高，而且容易遺忘，盡管項目負責人經常反復提醒，依舊無法避免人工操作不及時的問題，最終導致 JIRA 統計 LeadTime 流程被拉長，所以這是急需自動化的痛點
介紹到這里差不多了，我們來看看如何通過自動化的 workflow 簡化我們的開發環節：（這里僅僅代表我們團隊的工作流，並不適用於大部分的場景）
首先這里可以看到這個 issue 任務已經完成，處於等待上線的狀態（done） ：
開發人員只需在 GitLab 將對應的 TEST-225 分支提交 merge request，這里可以看到 GitLab 很智能的在 merge 描述中加入的觸發 JIRA issue 的關鍵字，merge request 生效后，對應的工作流也自動觸發了（狀態為 unresolved），如圖：
可以直接點擊描述的 issue 跳到 JIRA 系統查看
GitLab 如何批量觸發 JIRA 的工作量 ？
以上僅僅是對單個 Feature 的提交合並觸發工作流，但是日常開發中這種場景比較少，很多 Feature 通常都是批量發布和上線，以我們目前的項目為例，我們目前最大的痛點是 Feature 上線后可以自動觸發 Jira 的 On Line workflow，如果可以通過在 Release 合並進 Master 批量觸發工作流將可以大大的簡化我們目前的工作，提高效率。
在 GitLab 中有兩種方式可以實現批量觸發工作流，兩種實現方式不同，但各有利弊：
- Release 分支通過 Merge Request 的 Description 批量添加 Closes issue id 實現
- Feature 分支通過本地 commit -m 'Closes issue id' 然后合並到默認分支實現（master）
Release 分支通過 Merge Request 的 Description 批量添加 Closes issue id 實現
這種操作實現起來對項目經理和負責人要求會高一些，需要事先整理和匯總所有要上線的分支和對應的 issue ，然后 GitLab 會在 Release -> Master 節點的時候通過 Merge 的時候自動觸發 Jira 的工作流，那我們就需要在 Release 進行 Merge Request 的時候在合並描述 Description 添加觸發關鍵字 Closes Issue 即可，具體如圖所示：
在負責人點擊 Merge 對應的 issue 就會自動觸發 Jira 工作流，流轉對應的狀態
Feature 分支通過本地 commit -m 'Closes issue id' 然后合並到默認分支實現（master）
這種操作實現起來對開發人員要求會高一些，要求開發人員遵循規范，在完成 Feature 分支功能開發后，按照規范提交 commit 關鍵字來觸發工作流，具體如下：
git checkout phoenix/feature/TEST-223
git commit -m 'Closes TEST-223'
這種方式的好處是項目負責人不需要提前收集和整理 issue，也不需要在 Release 進行 Merge Request 的時候在合並描述 Description 添加觸發關鍵字，直接提交 Release 分支合並即可，具體如下：
它的工作原理是 GitLab 會自動在 Feature 分支的 commit log 找到觸發關鍵字然后執行自動化工作流，點擊 Merge 后通過 issue 鏈接跳轉過去就會發現 Jira 的狀態已經更新，非常方便，雖然兩種方式最終實現的效果都是一樣的，但是我個人比較推薦使用第二種方式，比較方便不說，而且可以培養開發人員的規范意識也是比較好的
總結
到這里集成工作就基本完成了，自從 GitLab 集成 JIRA 后開發團隊的效率和幸福感大增，從此過上了幸福的生活，距離走上人生的巔峰也不遠了………………
PS：這里只是進行了簡單的集成，如果大家發現更好的功能，可以分享出來交流和討論
參考資料：