領先一步
VMware 提供培訓和認證，以加速您的進度。
了解更多Spring Framework 從 Jira 遷移到 GitHub Issues
Spring Framework 已將其所有的 issue 歷史從 Jira 遷移到 GitHub。這篇部落格文章的目的是為您提供有關此搬遷的背景資訊和詳細資訊。
遷移詳細資訊
每個 Spring Framework issue 的所有 15 年以上的歷史記錄以及每個評論都已匯入到 GitHub 中。在這樣的搬遷中有很多需要考慮的，所以讓我們來瀏覽一下並查看一些細節。
連結
如果您有現有 issue 的連結，例如 https://jira.spring.io/browse/SPR-16751，您將被重新導向到對應的 GitHub issue。 如果您實際上想前往 Jira issue，請附加查詢參數 redirect=false。 在 GitHub 方面，匯入的 issue 有一個指向其 Jira issue 來源的回溯連結。
出現在文字中的 Jira issue key，例如 "SPR-16751"，已替換為 GitHub issue 參考，這樣的好處是在雙方的 issue 時間軸中插入連結。 另一個好處是當您將滑鼠游標停留在連結上時，可以獲得迷你預覽。
出現在文字中的其他 Spring 專案的 Jira issue key，例如 "DATAJPA-813"，已替換為連結。 例如，請參閱 #18558，其中包含指向 Spring Data JPA 的連結、#20904 指向 Spring Data MongoDB，以及 #16906 指向 Spring Integration Extensions。
出現在文字中的其他 GitHub 專案 issue 和 pull request 的連結，會獲得自動好處。 遷移後，引用 issue 的時間軸中有指向 Spring Framework 的連結，並且您可以在滑鼠游標懸停時獲得連結的預覽。 例如，請參閱 #21362，其中包含指向 Spring Boot 的連結、#20849 指向 JUnit，以及 #20256 指向 Jackson。
指向 GitHub 上任何專案的 commit 和原始碼的連結，也會獲得自動好處。 例如，請參閱 issue #18463 中指向原始碼範圍的連結。
Jira 詳細資訊
每個匯入的 issue 都會在描述的下半部分顯示來自 Jira 的資訊。 這樣做的目的是 GitHub 上提供來自 Jira 的所有資訊，您無需在兩者之間來回切換。 當可用時，您可能會看到以下一項或多項
- 受影響的版本
- 參考網址
- 附件
- 子任務和相關 issue
- Pull request 和 commit 參考
- 反向移植版本
- 投票和關注者數量
請注意，投票和關注訂閱無法轉移到 GitHub。 即使 spring-issuemaster 具有完整的權限，它也只能投票一次。 因此，請造訪 GitHub issue 並重新套用反應並訂閱以接收特定 issue 的更新。
標籤
某些 Jira 欄位已轉換為 GitHub issue 標籤
| Jira 欄位 | 標籤 |
|---|---|
| Issue 類型 | "type: *" |
| 狀態 | "status: *" |
| 解決方案 | "status: *" |
| 元件 | "in: *" |
兩個額外的標籤也已應用於匯入的 issue
| 標籤 | 描述 |
|---|---|
"has: votes-jira" |
具有 10 個以上投票的匯入 issue |
"has: backports" |
具有反向移植版本的 issue |
我們藉此機會簡化了 Jira 欄位值，因此例如 Jira 中的 25 個元件值對應於 GitHub 上的 5 個 "in: *" 標籤。 "status: *" 和 "type: *" 標籤也經過了額外的檢查和修訂。
我們選擇的標籤與 Spring Boot 中使用的標籤一致。 Boot 團隊對他們的流程和標籤進行了大量的思考，我們知道這種一致性將受到許多人的讚賞。 請參閱完整的標籤集。
在 Jira 中，許多欄位和標籤是可修改的。 在 GitHub 中，只有貢獻者才能新增或移除標籤。 這是完全合理的。 報告者只需描述 issue，而貢獻者對其進行分類。 開發人員和貢獻者都可以使用標籤進行搜尋。
修復版本
一個 Jira issue 可以有多個修復版本，而一個 GitHub issue 只能有一個目標里程碑。 這感覺像是一個缺點，但其中有更多的內容，而且這種限制迫使我們考慮一些有意義的調整。
以 SPR-17226 為例，其修復版本為 "4.3.19"、"5.0.9" 和 "5.1 RC3"。 雖然 issue 在所有 3 個版本中都已修復，但沒有必要污染當時仍在開發中的 "5.1 RC3" 的發行說明。 我們可以改為說它在 5.0.9 中修復並反向移植到 4.3.19，而貢獻者需要確保修復已傳播到仍在開發中的下一個版本。 這就是它在 GitHub issue #21759 上的顯示方式。 我們過去可以進行此調整嗎？ 當然，但 Jira 中對多個修復版本的支援並沒有迫使我們考慮。
這是一個小的調整，將產生更清晰的發行說明，但也會影響我們提交修復的方式。 當下一個版本正在 master 上開發時，我們將首先將修復套用到目前的生產分支，然後前向合併到 master，然後從較舊的生產分支中 cherry-pick。 而不是將修復套用到 master，然後從生產分支中 cherry-pick。 這樣做的結果是更乾淨的 commit 歷史記錄，因為前向合併有助於 git 了解相關變更。
至於反向移植，由於一個 issue 只能有一個目標里程碑，我們必須建立單獨的 issue 來表示修復的反向移植。 為了使用相同的範例，選擇 "5.0.9" 作為目標里程碑是值得的，因為我們只有一個反向移植 issue。 如果我們選擇 "5.1 RC3"，我們將需要兩個反向移植 issue。 為了讓您了解這會帶來多大的差異，假設 Spring Framework 從第一天起就在 GitHub Issues 上。 如果我們使用後一種方法，我們今天將大約有 2,500 個反向移植 issue。 如果我們使用前者，我們將大約有 1000 個。
對於歷史反向移植，我們為每個版本建立了一個 issue 持有者。 大約有 45 個。 展望未來，我們將為所有反向移植的修復程式建立單獨的 issue，這些 issue 將自動建立，主要用於發行追蹤。 至於討論，大多數對話應在主要 issue 上進行，而反向移植 issue 僅用於特定於反向移植的討論。
標記
毫無疑問，標記是遷移中最大且最痛苦的部分。 15 年的 issue 追蹤歷史反映了程式設計風格的重大轉變，這些風格反過來決定了評論中顯示的內容。
例如，一開始在評論中貼上了許多 XML，而 Markdown 將其視為 HTML 區塊，導致標籤根本沒有顯示。 當然，如果這些標籤用 {code:xml}...{code} 括起來，它看起來會很好，但在那些日子裡，標記並不常用，XML 片段仍然會顯示出來，不會強制 issue，因此無法正確遷移。
還有許多其他的細節，例如為了避免等寬字型的效果而必須跳脫大括號，或是為了避免星號作為粗體標記而消失必須跳脫星號。我就不詳述了。總之，我們投入了大量的精力，以確保標記轉換的品質達到合理的高水準。
需要特別強調的一個問題是在純文字（也就是程式碼區塊之外）中使用 "@"。這些是 GitHub 上的使用者提及，會觸發通知。您可能會驚訝地發現 @Bean、@Configuration、@Component 實際上是 GitHub 使用者。像 @andy、@arjen、@brian 這樣與 GitHub 使用者名稱衝突的名字引用也曾經很常見，在匯入超過 17,000 個 issue 及其評論時，這些都造成了很大的困擾。這就是我們為何花心思跳脫它們的原因。今後，在建立新的 issue 或評論時，請當個好的 GitHub 公民，使用反引號，例如 `@Foo` (是的，https://github.com/foo 確實存在)。
背景
我使用並喜歡 Jira 已經很長一段時間了。將遷移到 GitHub Issues 的想法並沒有立刻出現在我腦海中。相比之下，它似乎太過基本。讓我完全轉變想法的並非功能上的逐項比較，雖然我必須承認自從遷移以來，GitHub Issues 確實越來越受我喜愛。我暗示的是更大的潛在因素。
GitHub 是幾乎所有開源專案的所在地，包括 *每個* Spring 專案，而且所有使用者都可以合理地預期擁有 GitHub 憑證。因此，如今期望開發人員為他們所依賴或想要報告 issue 的每個開源專案維護一個單獨的 issue 追蹤系統登入資訊變得不切實際。
此外，將原始碼和 issue 放在一起還有許多好處。我之前提到過許多，例如在單一專案和 GitHub 上所有專案中，issue、pull request、原始碼和 commit 之間的自動連結參考。以及提及和通知任何 GitHub 使用者的能力。所有這些都是非常強大的優勢，在使用孤立的 issue 追蹤系統時根本不可能實現。我懷疑是否有人想回到開源專案託管在不同地方的時代。issue 追蹤也是如此。
原始碼和 issue 放在一起還有更深層、更不明顯的好處。GitHub 將 issue 和 pull request 視為平等。它們被分配來自相同序列的數字。它們看起來一樣（描述、評論、標籤和目標里程碑）。它們會無區別地出現在發布說明中。pull request 不過是附加了 commit 的 issue。
過去在 Spring Framework 中，我們堅持每個 pull request 都必須有一個 Jira issue。我們也不喜歡這個負擔，但我們需要一個記錄所有 issue 的單一地點。由於這種分裂的情況，永遠不太清楚應該在 pull request 下討論什麼，以及有多少應該屬於 Jira issue。
今後這不再是問題。我們希望有一個 issue 或一個 pull request，而不是兩者都有。如果您需要先從討論開始，我們 *確實* 鼓勵這樣做，請建立一個 issue，然後，如果您提交 pull request，PR 將取代該 issue。兩者仍然連結在一起，並且沒有任何遺失。對話只是跟隨行動。
不容忽視的是標記問題。我毫不懷疑 Wiki 標記對於與程式碼相關的討論來說很痛苦。我多年來每天都在使用它。我已經習慣了，但有些事情就是很難，而且需要太多的努力。以下提醒您在程式碼片段中顯示像大括號和星號這樣常見的東西需要做些什麼：{{/endpoint/\{server-id\}/\{session-id\}/\{transport/\*\}}}。
毫無疑問，Markdown 對於程式碼相關的評論來說更容易。它需要的打字較少，而且在格式化程式碼方面效果很好，因為它更簡單，並且不會與程式碼中常見的符號衝突。從一開始我就覺得這很明顯，因為我也同時使用 GitHub 和 Markdown 多年。我從來不明白為什麼 Jira 仍然不支援 Markdown。需要澄清的是，這不是一個決定性的因素。這只是你學會忍受的事情之一，後來可能會成為改變的額外動力。
最後但並非最不重要的是，如今大多數開發人員透過 Spring Boot 使用 Spring，Spring Boot 總是使用 GitHub Issues。僅從這個角度來看，Spring Framework 就有足夠的動機進行遷移，因為 Spring Boot 不會遷移到 Jira，而那是為 Spring 使用者創造更一致體驗的唯一其他方法。
實際遷移
儘管做了很多準備，但沒有什麼比實際遷移的那一天更令人難忘的了。我們使用了 GitHub 的非官方 匯入 API，該 API 文檔說明不會觸發任何通知。我們在測試期間沒有注意到任何問題。一旦實際遷移開始，每個 issue 和每個評論的通知都開始湧入。
我們開始使用所有可用的管道聯繫 GitHub 支援。幸運的是，他們也注意到了。他們怎麼可能沒注意到呢？據我估計，在我們停止之前匯入的 2,600 個 issue 必定產生了數千萬封電子郵件，毫不意外地造成了通知中斷。
一天後，在 GitHub 支援修正了問題並關閉了 Spring Framework 專案的所有通知以確保安全之後，我們走上了一條更順暢的道路，在 8-9 個小時內匯入了所有 issue。又花了幾個小時對所有 issue 和評論進行第二次處理，以將 Jira issue 金鑰替換為 GitHub 參考編號，然後又花了幾天時間檢查和清理標記轉換問題。
所有這些現在都已完成，我很榮幸地宣布我們現在在 GitHub Issues 上開始營業。