告別加班的煩惱，整合 java_bene && JIRA 實現自動化工作功能
前言
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 (usuallymaster) will close an issue in Jira. You can change your projects default branch underproject 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：這裡只是進行了簡單的整合，如果大家發現更好的功能，可以分享出來交流和討論