領先一步
VMware 提供培訓和認證，以加速您的進展。
了解更多Spring Data 從 Jira 遷移到 GitHub Issues
Spring Data 已將其所有的 Issue 歷史紀錄從 Jira 遷移到 GitHub。這篇部落格文章的目的是為您提供關於這次遷移的背景資訊與詳細資訊。
遷移細節
Spring Data Issues 已在 Jira 中管理超過十年。今天，每個 Issue 和每個評論都已匯入 GitHub。在這樣的遷移中有很多需要考慮，所以讓我們來瀏覽一下並檢閱一些細節。
Spring Data 由 19 個獨立專案組成，每個專案都與其自己的 Issue 追蹤命名空間相關聯。其中四個專案（Spring Data Build、BOM、Envers 和 R2DBC）已經在使用 GitHub。一個專案（Spring Data GemFire）未遷移，因為它處於維護模式，並且即將結束生命週期。在這次遷移中，我們將來自 14 個 Jira 專案的大約 15,000 個 Ticket 遷移到 14 個 GitHub 儲存庫。
Jira 細節
每個匯入的 Issue 都會在描述的下半部分顯示來自 Jira 的資訊。目標是讓來自 Jira 的所有資訊都可以在 GitHub 上取得，而您不必在兩者之間來回切換。您可能會看到以下一項或多項（如果有的話）：
- 受影響的版本
- 參考 URL
- 附件
- 相關 Issues
- Pull request 和 Commit 參考
- Backport 版本
- 投票和關注者計數
請注意，投票和關注訂閱無法轉移到 GitHub。即使 spring-issuemaster 具有完全權限，它也只能投票一次，而且無法代表其他人投票。因此，請訪問 GitHub Issues 以重新應用反應並訂閱以接收特定 Issue 的更新。
標籤
一些 Jira 欄位已轉換為 GitHub Issue 標籤
| Jira 欄位 | 標籤 |
|---|---|
| Issue 類型 | "type: *" |
| 狀態 | "status: *" |
| 解決方案 | "status: *" |
| 元件 | "in: *" |
還有兩個額外標籤應用於匯入的 Issues
| 標籤 | 描述 |
|---|---|
"has: votes-jira" |
具有 10 個以上投票的匯入 Issues |
"has: backports" |
具有 Backport 版本的 Issues |
我們利用這個機會簡化了所有儲存庫中的 Jira 欄位值。元件通過 "in: *" 標籤反映。"status: *" 和 "type: *" 標籤也經過額外的思考和修訂。典型的 Spring Data 專案具有以下元件：
| 標籤 | 描述 |
|---|---|
"in: core" |
核心支援 |
"in: mapping" |
對應元數據和轉換器基礎設施 |
"in: repository" |
儲存庫抽象 |
根據實際專案，您可以找到其他元件，例如 Spring Data MongoDB 的 "in: aggegation-framework"。因此，您可能會在 Spring Data REST 中找到在 Spring Data JPA 中不存在的元件。
我們選擇的標籤與 Spring Boot 和 Spring Framework 中使用的標籤一致。 Boot 團隊對他們的流程和標籤進行了很多思考，我們知道很多人會欣賞這種一致性。請參閱 Spring Data Commons 的完整標籤集。
在 Jira 中，許多欄位和標籤都是可修改的。在 GitHub 中，只有貢獻者可以新增或移除標籤。這非常有道理。回報者只需描述 Issue，而貢獻者則對其進行分類。開發人員和貢獻者都可以使用標籤進行搜尋。
展望未來，Spring Data 採用了一點自動化，這樣每個新的 Ticket 都必須由專案團隊進行分類，然後才能將 Ticket 接受為功能請求或錯誤報告。
修正版本
一個 Jira Issue 可以有多個修正版本，而一個 GitHub Issue 只能有一個目標里程碑。這感覺像是一個缺點，但還有更多顯而易見的原因，而且這個約束迫使我們考慮一些有意義的調整。
以 DATACMNS-715 為例，它具有修正版本 1.8.6、1.9.3、1.10.1 和 1.11 RC1。雖然這個 Issue 在所有四個版本中都已修正，但無法使用里程碑來表達這些。我們可以說它已在 1.8.6 中修正，並向前移植到所有其他版本。這就是它在 GitHub Issue #21759 上的顯示方式。我們過去可以進行此調整嗎？當然可以，但 Jira 中對多個修正版本的支援並沒有強迫我們這樣做。
標記
毫無疑問，標記是遷移中最重要也是最痛苦的部分。十年來的 Issue 追蹤歷史反映了程式設計風格的巨大轉變，進而決定了評論中顯示的內容。
例如，一開始在評論中貼上了很多 XML，而 Markdown 將其視為 HTML 區塊，導致標籤根本不顯示。當然，如果這些標籤被 {code:xml}...{code} 包圍，它看起來會很好，但在那些日子裡，標記並不常用，並且 XML 片段仍然顯示出來，所以它沒有強制執行這個 Issue，因此，不可能正確地遷移。
還有許多其他的複雜性（例如，轉義大括號，避免等寬字體的影響，或轉義星號以防止它們作為粗體標記消失）。我就不詳細介紹了。可以說我們付出了很多努力來確保標記轉換的品質相當高。
需要強調的一個具體 Issue 是在純文字（也就是在程式碼區塊之外）中使用 "@"。這些是 GitHub 上的使用者提及，會觸發通知。您可能會驚訝地發現 @Query、@Modifying、@Configuration 都是實際的 GitHub 使用者。這就是我們小心轉義它們的原因。展望未來，在建立新的 Issue 或評論時，請做一個好的 GitHub 公民並使用反引號（例如，`@Query`。
背景
我們已經使用並喜歡 Jira 很長時間了。遷移到 GitHub Issues 的想法並沒有立即出現在我們的團隊中。Jira 看起來太重要了。隨著時間的推移，我們看到 GitHub Issues 的採用率有所提高。我們的一些專案已經使用 GitHub，對於較新的專案，例如 Envers 和 R2DBC，我們從一開始就使用 GitHub Issues。我們還看到 Jira 中 Markdown 的使用率有所提高。最後，我們團隊看待專案的方式非常分散，因為沒有一個單一的視圖可以查看所有要處理的 Ticket。
GitHub 幾乎是每個開源專案的所在地，包括每個 Spring 專案，並且可以合理地期望所有使用者都擁有 GitHub 憑證。因此，現在期望開發人員為他們所依賴或想要回報 Issue 的每個開源專案的 Issue 追蹤器維護一個單獨的登入變得站不住腳了。
接著，將原始碼和議題協同定位有許多好處。我之前已經提過很多，像是議題、Pull Request、原始碼和 Commit 之間的自動連結參考，無論是在單一專案或 GitHub 上的所有專案之間，以及提及和通知任何 GitHub 使用者的能力。所有這些都是非常強大的好處，在孤立的議題追蹤系統中根本不可能實現。我懷疑是否有人想回到開源專案託管在不同地方的時代。議題追蹤也是如此。
對於協同定位的原始碼和議題，還有更深層、較不明顯的好處。GitHub 將議題和 Pull Request 同等看待。它們被賦予來自相同序列的編號，它們看起來相同（描述、評論、標籤和目標里程碑），它們在版本說明中沒有區別地出現。Pull Request 不過是一個附加了 Commit 的議題。
在 Spring Data 專案的歷史中，我們要求每個 Pull Request 都有一個 Jira 議題。我們也不喜歡這種負擔，但我們需要一個記錄所有議題的單一位置。由於這種分離的情況，始終不清楚應該在 Pull Request 下討論什麼，以及有多少屬於 Jira 議題。
今後，這不再是問題。我們期望的是議題或 Pull Request，而不是兩者都有。如果您需要先從討論開始，我們確實鼓勵這樣做，請建立一個議題，然後，如果您提交 Pull Request，PR 將取代該議題。兩者仍然連結在一起，而且沒有任何遺失。對話跟隨行動。
不可忽略的是標記問題。毫無疑問，根據不同的議題追蹤器使用不同的標記變體是很痛苦的。毫無疑問，Markdown 廣泛使用且易於在與程式碼相關的討論中使用。與 Jira 的 Wiki 標記相比，它需要的輸入更少，而且在格式化程式碼方面效果很好，因為它更簡單且不會與程式碼中常見的符號衝突。從一開始這對我來說就很明顯，因為我多年來也同時使用 GitHub 和 Markdown。Jira 是 Atlassian 最古老的產品之一，因此有一些歷史原因導致沒有現成的 Markdown 支援。需要澄清的是，這並不是一個決定性的因素。這只是你學會忍受的一件事，後來可能會成為改變的額外動力。
最後但同樣重要的是，今天，大多數開發人員透過 Spring Boot 使用 Spring，而 Spring Boot 一直使用 GitHub Issues。Spring Framework 已經使用 GitHub Issues 兩年了。僅從這個角度來看，就足以激勵 Spring Data 遷移，並為 Spring 用戶創建更一致的體驗。
遷移到 GitHub 議題讓我們團隊有機會重新考慮或調整 Commit 訊息格式。自創建以來，Spring Data 訊息遵循 <ticketnumber> - summary. 的模式。這種格式過去對我們來說運作良好。遷移到 GitHub 後，Ticket Number 以井字號 (#) 開頭，通常用作註解字元。因此，更改 Commit 訊息或修改 Commit 變得麻煩，因為每個提交者都需要調整其 Git 配置，以避免將 # 視為註解字元。未來，GitHub 允許透過在 Commit 訊息中引用 Ticket 來關閉 Ticket 和 Pull Request。
因此，我們未來的 Commit 訊息將更像這樣
Summary.
Body comes here.
Original pull request #456
Closes #123
實際遷移
儘管做了很多準備，但沒有什麼比實際遷移的那一天更重要了。我們使用了 GitHub 的非官方 匯入 API，據文檔說明不會觸發任何通知。偶爾，由於它們的內容大小，個別議題的匯入會失敗。特別是貼上原始的 StackOverflowExceptions 會導致很大的議題內容，需要截斷。
考慮到這一點，我們在兩天內遷移了所有 14 個專案。又花了幾個小時再次檢查所有議題和評論，以將 Jira 議題金鑰替換為 GitHub 參考編號。
所有這些現在都已完成，我很榮幸地宣布我們現在可以在 GitHub Issues 上開放業務了。