领先一步
VMware提供培训和认证，以加速您的进步。
了解更多Spring Data从Jira迁移到GitHub Issues
Spring Data已将其所有问题历史记录从Jira迁移到GitHub。这篇博客文章的目的是向您提供有关此迁移的背景和详细信息。
迁移细节
Spring Data 的问题在 Jira 中管理了十多年。今天，每个问题和每条评论都已导入到 GitHub。此类迁移需要考虑很多因素，因此让我们来了解一些细节。
Spring Data 包含 19 个独立项目，每个项目都与其自身的 Issue Tracker 命名空间关联。四个项目（Spring Data Build、BOM、Envers 和 R2DBC）一直在使用 GitHub。一个项目（Spring Data GemFire）没有迁移，因为它处于维护模式，很快就会停止生命周期。在此迁移过程中，我们从 14 个 Jira 项目迁移了近 15,000 张工单到 14 个 GitHub 存储库中。
Jira 细节
每个导入的问题都会在其描述的下半部分显示来自 Jira 的信息。目标是所有 Jira 信息都可以在 GitHub 上获得，而无需在两者之间来回切换。如果可用，您可能会看到以下一项或多项：
- 受影响的版本
- 参考 URL
- 附件
- 相关问题
- Pull Request 和提交引用
- 回传版本
- 投票和观察者计数
请注意，投票和观察订阅无法迁移到 GitHub。即使`spring-issuemaster`拥有完全权限，它也只能投票一次，并且无法代表他人投票。因此，请访问 GitHub Issues 以重新应用反应并订阅以接收特定问题的更新。
标签
一些 Jira 字段已转换为 GitHub Issue 标签
| Jira 字段 | 标签 |
|---|---|
| 问题类型 | "type: *" |
| 状态 | "status: *" |
| 解决方案 | "status: *" |
| 组件 | "in: *" |
还应用了两个额外的标签到导入的问题
| 标签 | 描述 |
|---|---|
"has: votes-jira" |
拥有 10 多个投票的导入问题 |
"has: backports" |
具有回传版本的 Issue |
我们利用这次机会简化了所有存储库中的 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 中，只有贡献者才能添加或删除标签。这是非常合理的。报告者只是描述问题，而贡献者对其进行分类。开发人员和贡献者都可以使用标签进行搜索。
展望未来，Spring Data 将采用一些自动化措施，这样每个新工单都必须由项目团队进行分类，然后才能将其作为功能请求或错误报告接受。
修复版本
一个 Jira Issue 可以有多个修复版本，而一个 GitHub Issue 只能有一个目标里程碑。这感觉像是一个缺点，但其中还有更多不为人知的东西，而且这个限制迫使我们考虑一些有意义的调整。
例如，DATACMNS-715，其修复版本为`1.8.6`、`1.9.3`、`1.10.1`和`1.11 RC1`。虽然该问题在这四个版本中都已修复，但无法使用里程碑来表达这些。相反，我们可以说它在`1.8.6`中得到修复，并向前移植到所有其他版本。这就是它在 GitHub Issue #21759上的显示方式。我们过去能否进行这种调整？当然可以，但是 Jira 中对多个修复版本的支持并没有迫使我们这样做。
标记
毫无疑问，标记是迁移中最重要和最痛苦的部分。十年的问题跟踪历史反映了编程风格的巨大变化，而这些变化反过来又决定了评论中显示的内容。
例如，一开始在评论中粘贴了很多 XML，而 Markdown 将其视为HTML 块，导致标签根本不显示。当然，如果这些标签用`{code:xml}...{code}`包围，它看起来会很好，但在那些日子里，标记并不常用，XML 代码片段无论如何都会显示出来，所以它并没有强制解决这个问题，因此无法正确迁移。
还有许多其他复杂之处（例如转义大括号、避免单空格的影响或转义星号以防止它们作为粗体标记消失）。我将省去这些细节。可以肯定地说，我们付出了很多努力来确保标记转换质量相当高。
需要重点说明的一个具体问题是在纯文本中使用“@”（即，在代码块之外）。这些是 GitHub 上触发通知的用户提及。您可能会惊讶地发现@Query、@Modifying、@Configuration 实际上是 GitHub 用户。这就是为什么我们小心地对其进行转义的原因。展望未来，在创建新问题或评论时，请做一个合格的 GitHub 用户，并使用反引号（例如，`@Query`）。
背景
我们已经使用了 Jira 很长时间，并且很喜欢它。迁移到 GitHub Issues 的想法并没有立即出现在我们的团队中。Jira 似乎太重要了。随着时间的推移，我们看到 GitHub Issues 的采用率不断增长。我们的一些项目已经使用了 GitHub，对于较新的项目（例如 Envers 和 R2DBC），我们从一开始就使用了 GitHub Issues。我们还看到 Jira 中 Markdown 的使用率有所提高。最后，我们团队看待项目的角度非常分散，因为没有对所有需要处理的工单进行单一视图。
GitHub 几乎是每个开源项目的所在地，包括*每个*Spring 项目，并且可以合理地预期所有用户都拥有 GitHub 凭据。因此，如今指望开发人员为他们依赖或想要对其报告问题的每个开源项目的 Issue Tracker 保持单独的登录名已变得不可行。
将源码和问题放在一起有很多好处。我之前提到了很多，例如跨问题、拉取请求、源码和提交的自动链接引用，这些链接在一个项目中以及GitHub上的所有项目之间都有效，并且能够提及和通知任何GitHub用户。所有这些都是非常强大的优势，而孤立的问题跟踪是无法实现的。我怀疑没有人想回到开源项目托管在不同地方的日子。问题跟踪也是如此。
将源码和问题放在一起还有更深层次、不那么明显的优势。GitHub平等对待问题和拉取请求。它们从同一个序列中分配编号，外观相同（描述、评论、标签和目标里程碑），它们在发行说明中没有区别地出现。拉取请求只不过是附加了提交的问题。
历史上，在Spring Data项目中，我们要求每个拉取请求都对应一个Jira问题。我们也不喜欢这种负担，但我们需要一个记录所有问题的单一位置。由于这种分离的情况，拉取请求中应该讨论什么以及Jira问题中应该包含多少内容从来都不明确。
未来，这不再是问题。我们期望一个问题或一个拉取请求，而不是两者兼有。如果您需要先开始讨论（我们_确实_鼓励这样做），请创建一个问题，之后如果您提交了一个拉取请求，PR将取代该问题。两者仍然链接在一起，什么都不会丢失。对话跟随行动。
不容忽视的是标记问题。毫无疑问，根据问题跟踪器使用不同的标记变体是很痛苦的。毫无疑问，Markdown在与代码相关的讨论中被广泛使用并且易于使用。与Jira的Wiki标记相比，它需要更少的输入，并且在格式化代码时就能正常工作，因为它更简单，并且不会与代码中常见的符号冲突。从一开始我就觉得这很明显，因为我多年来也并行使用了GitHub和Markdown。Jira是Atlassian最古老的产品之一，因此关于为什么没有开箱即用的Markdown支持有一些历史原因。需要明确的是，这并不是决定性因素。它只是那些你学会忍受的事情之一，后来可能会成为改变的额外动力。
最后但并非最不重要的一点是，今天，大多数开发者通过Spring Boot使用Spring，而Spring Boot一直使用GitHub Issues。Spring Framework已经使用了GitHub Issues两年了。仅从这个角度来看，Spring Data就有足够的动力迁移并为Spring用户创造更一致的体验。
迁移到GitHub Issues为我们团队提供了一个重新考虑或提交消息格式的机会。自创建以来，Spring Data消息遵循<ticketnumber> - summary.模式。这种格式过去对我们很有效。迁移到GitHub后，工单号以哈希（#）开头，通常用作注释字符。因此，更改提交消息或修改提交成为负担，因为每个提交者都需要调整其Git配置，以不将#视为注释字符。未来，GitHub允许通过在提交消息中引用工单来关闭工单和拉取请求。
因此，我们未来的提交消息将更像
Summary.
Body comes here.
Original pull request #456
Closes #123
实际迁移
尽管做了很多准备，但没有什么比得上实际迁移的那一天。我们使用了GitHub的非官方导入API，该API的文档说明不会触发任何通知。偶尔，由于正文大小的原因，单个问题的导入会失败。特别是粘贴原始StackOverflowExceptions会导致大型问题正文需要截断。
考虑到这一点，我们在两天内迁移了所有14个项目。又花了几小时对所有问题和评论进行第二次处理，以将Jira问题密钥替换为GitHub参考编号。
所有这些现在都完成了，我很高兴地宣布我们现在在GitHub Issues上开放业务。