领先一步
VMware 提供培训和认证，助您加速进步。
了解更多Spring Data 从 Jira 迁移到 GitHub Issues
Spring Data 已将其完整的 Issue 历史记录从 Jira 迁移到 GitHub。本文旨在为您提供有关此次迁移的背景信息和详细信息。
迁移详情
Spring Data 的 Issue 在 Jira 中管理了十多年。今天，每个 Issue 和每个评论都已导入到 GitHub 中。这样的迁移有很多需要考虑的事项，所以让我们一起了解一下详细信息。
Spring Data 由 19 个独立项目组成，每个项目都与其自己的 Issue 跟踪命名空间相关联。有四个项目（Spring Data Build、BOM、Envers 和 R2DBC）一直在使用 GitHub。一个项目（Spring Data GemFire）由于处于维护模式并将很快终止生命周期而未进行迁移。在本次迁移中，我们将近 15,000 个工单从 14 个 Jira 项目迁移到了 14 个 GitHub 仓库中。
Jira 详情
每个导入的 Issue 在其描述的下半部分显示了来自 Jira 的信息。目的是让 Jira 中的所有信息都在 GitHub 上可用，您不必在两者之间来回切换。在可用时，您可能会看到以下一项或多项内容：
- 受影响的版本
- 参考 URL
- 附件
- 相关 Issue
- Pull Request 和提交引用
- 回溯版本
- 投票和关注者数量
请注意，投票和关注订阅无法迁移到 GitHub。即使 spring-issuemaster 拥有完全权限，它也只能投一票，并且无法代表他人投票。因此，请访问 GitHub Issues 以重新应用反应并订阅特定 Issue 的更新。
标签
一些 Jira 字段被转换为 GitHub Issue 标签
| Jira 字段 | 标签 |
|---|---|
| Issue 类型 | "type: *" |
| 状态 | "status: *" |
| 解决方案 | "status: *" |
| 组件 | "in: *" |
另外两个标签也应用于导入的 Issue
| 标签 | 描述 |
|---|---|
"has: votes-jira" |
导入的 Issue 投票数超过 10 |
"has: backports" |
包含回溯版本的 Issue |
我们借此机会简化了所有仓库的 Jira 字段值。组件通过 "in: *" 标签体现。"status: *" 和 "type: *" 标签也经过了仔细思考和修订。一个典型的 Spring Data 项目包含以下组件：
| 标签 | 描述 |
|---|---|
"in: core" |
核心支持 |
"in: mapping" |
映射元数据和转换器基础设施 |
"in: repository" |
仓库抽象 |
根据实际项目，您可能会找到额外的组件，例如 Spring Data MongoDB 的 "in: aggregation-framework"。因此，您可能会在 Spring Data REST 中找到在 Spring Data JPA 中不存在的组件。
我们选择的标签与 Spring Boot 和 Spring Framework 中使用的标签保持一致。Boot 团队对他们的流程和标签进行了深入思考，我们知道很多人会赞赏这种一致性。请参阅 Spring Data Commons 的完整标签集。
在 Jira 中，许多字段和标签是可修改的。在 GitHub 中，只有贡献者可以添加或删除标签。这是完全合理的。报告者只需描述 Issue，而贡献者则对其进行分类。开发者和贡献者都可以使用标签进行搜索。
未来，Spring Data 将采用一些自动化措施，以便每个新工单在被接受为功能请求或错误报告之前，必须由项目团队进行分类处理。
修复版本
一个 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 片段无论如何都会显示，所以它没有强制使用标记，因此导致无法正确迁移。
还有许多其他的复杂性（例如大括号的转义、避免等宽字体的影响或转义星号以防止它们作为粗体标记消失）。我将不赘述细节。只需说我们投入了大量精力来确保标记转换的质量相当高。
需要强调的一个具体问题是在纯文本中使用“@”（即在代码块之外）。这些在 GitHub 上是用户提及，会触发通知。您可能会惊讶地发现 @Query、@Modifying、@Configuration 是真实的 GitHub 用户。这就是为什么我们特意对它们进行了转义。将来，在创建新 Issue 或评论时，请做一个好 GitHub 公民，并使用反引号（例如，`@Query`）来表示代码或关键字。
背景
我们长期以来一直使用并喜欢 Jira。迁移到 GitHub Issues 的想法并非立即出现在我们团队中。Jira 似乎太重要了。随着时间的推移，我们看到了 GitHub Issues 采用率的增长。我们的一些项目已经在使用 GitHub，对于 Envers 和 R2DBC 等较新的项目，我们从一开始就使用了 GitHub Issues。我们还注意到 Jira 中 Markdown 的使用量有所增加。最后，我们团队看待项目的方式相当分散，因为没有一个单一的视图可以查看所有待处理的工单。
GitHub 几乎是所有开源项目的所在地，包括 所有 Spring 项目，并且所有用户都可以合理地被期望拥有 GitHub 凭据。因此，如今期望开发者为他们所依赖的或想要报告问题的每个开源项目的 Issue 跟踪器维护单独的登录已变得不可行。
此外，将源代码和 Issue 放在一起还有诸多益处。我之前提到了许多，例如在单个项目内以及 GitHub 上的所有项目之间，Issue、Pull Request、源代码和提交的自动链接引用，以及提及和通知任何 GitHub 用户的能力。所有这些都是非常强大的优势，而孤立的 Issue 跟踪器根本无法实现。我怀疑是否有人想回到开源项目托管在不同地方的时代。对于 Issue 跟踪也是如此。
将源代码和 Issue 放在一起还有更深层、不太明显的益处。GitHub 平等对待 Issue 和 Pull Request。它们从同一序列中分配编号，外观相同（描述、评论、标签和目标里程碑），并在发布说明中无区别地出现。Pull Request 不过是一个附带提交的 Issue。
历史上，在 Spring Data 项目中，我们要求每个 Pull Request 都对应一个 Jira Issue。我们也不喜欢这个负担，但我们需要一个单一的地方来记录所有 Issue。这种分离情况导致 Pull Request 下应该讨论什么以及多少内容属于 Jira Issue，从未太清楚。
将来，这不再是一个问题。我们期望提交 Issue 或 Pull Request 中的一个，而不是两者。如果您需要先进行讨论（我们确实鼓励这样做），请创建一个 Issue，然后，如果您提交 Pull Request，PR 将取代该 Issue。两者仍然相互链接，不会丢失任何内容。对话会随着行动进行。
不可忽视的是标记问题。毫无疑问，根据 Issue 跟踪器的不同使用不同的标记变体是痛苦的。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 允许通过在提交消息中引用工单来关闭工单和 Pull Request。
因此，我们未来的提交消息将更像这样：
Summary.
Body comes here.
Original pull request #456
Closes #123
实际迁移
尽管做了大量准备，但实际迁移日的那一天是无可比拟的。我们使用了 GitHub 非官方的导入 API，该 API 文档说明不会触发任何通知。偶尔，由于 Issue 主体大小的原因，某些 Issue 的导入会失败。特别是粘贴原始的 StackOverflowExceptions 会导致 Issue 主体过大，需要截断。
考虑到这一点，我们在两天内迁移了所有 14 个项目。又花费了几个小时对所有 Issue 和评论进行了第二次处理，用 GitHub 参考编号替换了 Jira Issue 键。
所有这些现已完成，我很高兴宣布我们现在已在 GitHub Issues 上开放接受业务。