準時下班的祕密：集成 GitLab && JIRA 實現自動化工做流

佛羅倫薩 - 聖母百花聖殿（圖）

前言

GitLab 和 Jira 是平時開發過程當中使用很是高頻的代碼管理系統（開發人員）和項目管理系統（項目管理），經過兩套系統的協做完成日常大多數的功能開發，可是兩套系統在沒有集成狀況下是徹底兩套獨立的系統，不只信息沒有互通，並且開發人員須要反覆的登錄兩套不一樣的系統，進行一些重複的操做才能保證功能流的正常流轉，不只效率低下，浪費時間和人力，並且由於人自己的不可靠屬性，因此致使狀態的流轉並不能很是的及時和準確，這種重複和機械的動做偏偏是自動化所擅長的地方，今天我介紹一下如何集成 GitLab 和 Jira 的工做流，提升團隊的開發體驗，提高你們的開發效率，能夠把騰出的精力和時間都放在更有價值的事情上

1. GitLab 如何開啓 JIRA 的入口？
2. GitLab 如何打通 JIRA 的信息流？
3. GitLab 如何自動化 JIRA 的工做流（workflow）？
4. 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)：這裏比較關鍵，是自動化工做流的核心，有如下幾點注意事項：
  1. 首先這裏是指 GitLab commit or merge 動做關鍵字觸發對應的 JIRA workflow ID（狀態 ID，多個狀態使用 , or ; 號分割）
  2. 限制：workflow id 必須是連續的狀態，若是是有中間狀態則會跳轉失敗
  3. 只會對 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.

我在這裏簡單轉述一下：

1. 只有默認分支（master 能夠在 GitLab -> Settings 中配置）的 commit and merge 會觸發關閉 JIRA issue
2. 已有解決方案的 JIRA issue 則不會發生狀態流轉（就是我以前說的：只會對 JIRA.issue.status.resolution = unresolved 的 issues 生效）

咱們目前的痛點是：

每次需求上線後，都開發人員在 JIRA 裏面點 On Line 來肯定功能已經發布，可是此時 On Line 狀態的需求一般不掛在開發人員身上，開發人員每次需求上線後須要作如下操做：

1. 登錄 Jira 系統，輸入帳號密碼
2. 找到項目，經過需求編號，找到對應已經上線的需求
3. 在狀態項點擊 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：這裏只是進行了簡單的集成，若是你們發現更好的功能，能夠分享出來交流和討論

參考資料：

• GitLab Jira integration