Spring Framework已經將整個問題跟蹤系統從Jira遷移到GitHub，本文將介紹這次遷移的背景和相關的細節。
遷移細節
Spring Framework整整15年的問題和相關注解都已經被導入GitHub，這樣的一個遷移需要考慮很多事項，接下來將介紹其中的一些細節。
鏈接
指向現有問題的鏈接，例如https://jira.spring.io/browse/SPR-16751，將被重定向到相應的GitHub問題上。如果你確實想要轉到Jira，可以在URL後面加上redirect=false。導入到GitHub的問題都會有一個指向Jira來源的鏈接。
Jira問題的名字，例如“SPR-16751”，被替換成GitHub的命名方式，這有利於在時間表中插入鏈接，而且當鼠標懸停在鏈接上時，可以進行初步預覽。
其他Spring項目的Jira問題的名字，例如“DATAJPA-813”，也被替換成鏈接。例如，#18558指向Spring Data JPA，#20904指向Spring Data MongoDB，#16906指向Spring Integration Extensions。
在遷移之後，時間表中就會包含指向Spring的問題鏈接，可以通過鼠標懸停在鏈接上進行預覽。例如，#21362指向Spring Boot，#20849指向JUnit，#20256指向Jackson。
到其他GitHub項目代碼的鏈接也同樣會獲得這些好處。
Jira的詳細信息
每個被導入到GitHub的問題都會在其描述的下半部分顯示原始的Jira信息。也就是說，來自Jira的所有信息都可以在GitHub上獲得，不必在兩者之間來回跳轉。你可能會看到以下的一項或多項內容：
- 受影響的版本；
- 參考URL；
- 附件；
- 子任務和相關問題；
- 拉取請求和提交；
- backport版本；
- 投票數和關注者數量。
但請注意，投票和關注訂閱無法被轉移到GitHub。即使spring-issuemaster擁有完全權限，它也只能投一次票。因此，用戶需要請訪問GitHub並重新訂閱，這樣才能接收到特定問題的更新通知。
標籤
一些Jira字段被轉換爲GitHub問題標籤。
| Jira字段 | GitHub標籤 |
|---|---|
| Issue Type | “type: *” |
| Status | “status: *” |
| Resolution | “status: *” |
| Component | “in: *” |
另外兩個標籤也適用於導入的問題。
| GitHub標籤 | 描述 |
|---|---|
| “has: votes-jira” | 導入的問題包含10個以上投票 |
| “has: backports” | 包含backport版本的問題 |
我們利用這個機會簡化了Jira字段的值，例如Jira中組件的25個值對應於GitHub中“in：”標籤的5個值。“status：”和“type：*”標籤的值也已經過修改。
我們選擇的標籤與Spring Boot中使用的標籤保持一致。Spring Boot團隊已經針對他們的過程和標籤做過很周全的考慮，在這裏可以查看完整的標籤集。
在Jira中，很多字段和標籤都是可修改的。但在GitHub中，只有貢獻者可以添加或刪除標籤。這很有道理，因爲問題報告者只需要描述問題，然後讓貢獻者對其進行分類。開發者和貢獻者都可以使用標籤進行搜索。
修復版本
一個GitHub問題只能有一個目標里程碑（即“修復版本”），而一個Jira問題可以有多個修復版本。這感覺就像一個缺點，但它迫使我們考慮做出一些有意義的調整。
例如，SPR-17226有修復版本“4.3.19”、“5.0.9”和“5.1 RC3”，而導入的問題#21759將“5.0.9”作爲目標里程碑，將“4.3.19”作爲backport版本。這樣很完美，即問題是在當前的生產分支（截至2018年8月的5.0.x）而不是預發佈的“5.1 RC3”版本中得到修復的。我們打算在即將到來的5.2開發週期中遵循這一流程，在當前生產分支（5.1.x）修復問題，然後合併到master（面向5.2），在這個時候可能有少量問題需要backport到4.3.x.
對於歷史性的backport問題，我們爲每個版本的backport問題創建了一個問題引用，總共大約有45個。在未來，我們打算使用單獨的問題來代表backport問題。這些問題將被自動創建並用於發佈跟蹤。
標記
毫無疑問標記是整個遷移過程最大也是最痛苦的部分。15年的問題跟蹤歷史反映出了編程風格的重大轉變，而這反過來決定了註解中會出現什麼樣的內容。
例如，人們最開始直接將XML粘貼在註解中，Markdown會將它們視爲HTML塊，導致標籤無法正常顯示。當然，如果它們被包含在{code:xml}…{code}中看起來會好很多，但在那些日子裏，人們並不經常使用這個標記，不管怎樣總是會出現XML片段，給正常遷移帶來了很大麻煩。
還有很多其他錯綜複雜的問題，比如轉義花括號來避免出現單空格效應，或者轉義星號以防止它們被當作粗體標記。我們付出了很多努力來確保高質量的標記轉換。
需要特別說明的一個問題是在純文本中（即在代碼塊之外）使用“@”。這個符號用於給GitHub用戶觸發通知。令人感到驚訝的是，居然有人使用@Bean、@Configuration、@Component作爲GitHub用戶名，像@andy、@arjen、@brian與GitHub用戶名衝突的情況也很常見，所有這些對於導入帶有註解的17K+個問題來說都是一個巨大的麻煩。這就是爲什麼我們要對它們進行轉義。在未來，在創建新問題或註解時，請使用反引號，例如： @Foo。
遷移背景
我已經使用Jira很長時間了，也很喜歡它。遷移到GitHub Issues並非突發奇想。轉向GitHub並不是因爲它的功能，雖然我必須承認從遷移到GitHub Issues開始，它們確實對我產生了一定的影響。
GitHub是幾乎所有開源項目的所在地，包括所有的Spring項目，並且幾乎所有用戶都有一個GitHub賬號。因此，讓開發人員爲他們所依賴的每個開源項目或問題跟蹤器使用單獨的登錄賬號有點不切實際。
另外，將源代碼和問題放在同一個地方也有好處，比如可以在單個項目或者GitHub的所有項目中自動鏈接引用問題、拉取請求、源代碼和源碼提交，並且可以在註解等地方提及和通知GitHub用戶。所有這些好處是單獨的問題跟蹤系統無法提供的。我懷疑是否有人想要回到過去，那個時候開源項目託管在不同的地方。對於問題跟蹤系統來說也是一樣。
將源代碼和問題跟蹤系統放在一起有更深層次的好處，這些好處可能沒有那麼顯而易見。GitHub對問題和拉取請求同等對待，使用了同一個序列號爲它們分配編號。它們看起來是一樣的（描述、註解、標籤和目標里程碑）。它們都出現在發行說明中，幾乎完全一樣。拉取請求只不過是附加了源代碼提交的問題。
在Spring Framework的歷史上，我們堅持每個拉取請求都對應一個Jira問題。我們也不喜歡這種負擔，但我們需要一個系統來記錄所有的問題。由於存在這種分裂的情況，哪些東西應該針對拉取請求以及哪些應該屬於Jira問題，一直以來都不太明確。
但在未來，這不再是個問題。我們期待同時只有一個問題或者拉取請求，而不是兩者都有。如果你要討論問題，建議先創建一個問題，如果稍後提交了拉取請求，拉取請求將取代問題。這兩者仍然會關聯在一起，不會丟失任何內容。
標記是一個不容忽視的問題。毫無疑問，我認爲Wiki標記對於與代碼相關的註解來說是一個痛點。我已經用它好幾年時間了，而且幾乎每天都用。我已經習慣了，但有些標記使用起來仍然很麻煩，需要付出很大的努力。這裏順便提醒一下，在代碼片段中顯示像花括號和星號這些常見的符號時需要這樣：{{/endpoint/{server-id}/{session-id}/{transport/*}}}。
在與代碼相關的註解中使用Markdown會更容易些。它需要更少的輸入，在格式化代碼方面也沒有什麼問題，因爲它更簡單，並且不會與代碼中的符號衝突。我來從一開始就注意到這一點，因爲我也在同時使用GitHub和Markdown。我不明白爲什麼Jira仍然不支持Markdown，但這不是一個決定性的因素。
最後，如今大多數開發人員使用了Spring Boot，而它一直在使用GitHub Issues。單從這個角度來看，Spring Framework就有足夠的動力進行遷移，因爲Spring Boot不可能會遷移到Jira，所以這是爲Spring用戶提供一致性體驗的唯一方法。
實際的遷移
儘管做了很多準備工作，但實際的遷移卻與預想的完全不一樣。我們使用了非官方的GitHub導入API（https://gist.github.com/jonmagic/5282384165e0f86ef105），API文檔中說不會觸發任何通知。我們在測試期間沒有發現任何問題，但在開始實際的遷移後，與問題和註解相關的通知如洪水般涌入。
我們通過各種渠道與GitHub支持團隊取得聯繫。所幸的是，他們也注意到了這個問題。他們怎麼會注意不到？根據我的估計，在我們撤消之前導入的2,600個問題應該會產生數千萬封電子郵件，所以導致通知系統中斷一點也不足爲奇。
一天後，在GitHub支持團隊修復了問題並關閉了Spring Framework項目的所有通知後，我們很順利地在8-9小時內導入了所有問題。隨後，我們花了幾個小時使用GitHub的名稱格式替換了Jira的問題名字，還花了幾天時間檢查和清理標記轉換問題。
英文原文：https://spring.io/blog/2019/01/15/spring-framework-s-migration-from-jira-to-github-issues