已经使用 OpenAPI 的团队认识到集中式 SwaggerHub 解决方案的价值，但迁移和配置大量服务定义可能会让人感到繁琐。在过去几周中，SwaggerHub 团队对开源构建插件进行了重大更新，以轻松自动化此工作流程，并使团队能够更快地加入该平台。
第一个功能带来了将定义批量迁移到 SwaggerHub 的能力。可以解析 OpenAPI 定义的目录并将其推送到平台中，从而大大减少了开始使用和组织新的集中式环境所需的时间。
为了更容易地将定义与代码联系起来，该插件现在会自动配置一个 SCM 集成，以在 SwaggerHub 中存储的定义与在构建环境中生成和部署的定义之间建立双向关系。对定义进行更改时，它们会自动推送到构建过程中配置的存储库。此功能允许团队利用 OpenAPI 的强大功能，无论他们传统上在开发实践中是设计优先还是代码优先。
为了了解有关该插件及其相关工作的更多信息，我们与 SwaggerHub 的一位位于戈尔韦的开发人员 Michael Melody 进行了交谈，了解了他使用该插件的经验、平衡开源和付费开发任务以及他对 API 开发设计优先方法的看法。
您加入 SwaggerHub 团队多久了？
我于 2018 年夏天加入。作为戈尔韦的开发人员，并且在之前的工作中使用过 SmartBear 产品，我一直都知道 SmartBear 在这个城市的存在。当出现这个职位时，我立即抓住了加入团队的机会！
您的开发背景是什么？您过去是否参与过其他开源项目？
自 2014 年大学毕业以来，我从事专业开发已有近 5 年。参与开源一直是我的梦想，但从未实现过。到目前为止，参与开源的体验一直很好。
该插件的更新将真正使许多希望迁移到该平台的组织受益——更改的开发工作是什么？这是一个单独的项目，还是有一组开发人员参与其中？
整个团队都付出了巨大的努力，才使该插件达到今天的水平。该插件最初是在 Smartbear 举行的黑客马拉松中诞生的。我们以前的一位开发人员（向 John French 致敬 - 即使他离开了我们，他仍然通过 PR 继续贡献）设计了该插件，使我们能够在构建过程中获取 API 定义。
最近，作为最新版本的一部分，我们中的一些人致力于完成此工作并确保它具有最高质量；从参与设计讨论和审查拉取请求的开发人员到在测试时对插件进行全面测试的 QA。
团队遵循粗略的时间表吗？
在时间表方面，我们计划在 3 个 2 周的冲刺中开发该插件并对 SwaggerHub 后端进行更改。我们通过将交付 v1.0.3 所需的内容分解为 3 个较小的开发块来实现此目标
- 多定义上传
- 所需的 SwaggerHub 后端更新
- GitHub 集成配置
回顾来看，我们本可以在第一个冲刺后发布该插件，以便比我们实际做的更早地交付某些功能。这是我们将在未来开发中采纳的经验。
该插件是 SmartBear 支持的更大规模的开源项目集合的一部分，从 Swagger 工具到用于 API 测试的 SoapUI - 您通常参与 SwaggerHub 平台，还是支持开源项目？
是的，在大多数情况下，我只参与 SwaggerHub 平台。作为我在开发团队中的一部分角色，我在将最新的 Codegen 更改发布到 SwaggerHub 时与开源开发人员合作。对我来说，这涉及到测试某些功能并在 SwaggerHub 端进行必要的更改以合并它们。
您认为 SmartBear 支持像 SwaggerHub 这样的付费解决方案以及开源工具的方法是一种优势吗？
我之前提到了 Codegen，它本身是开源的，也是 SwaggerHub 产品的一部分。对我来说，我与 SwaggerHub 的第一次互动是使用生成服务器/客户端功能。我在尝试学习其他语言以及开始自己的项目时将其用作参考点。从这个角度来看，它是一个优势，因为它有助于形成 SwaggerHub 的关键组成部分。
通过支持开源工具，像 SwaggerHub 这样的付费解决方案显然会带来好处。例如，该插件使客户能够比以前更快地迁移到该平台，从而改善了他们的用户体验。其他开源组件（如 swagger 解析器）构成了我们的后端架构的一部分，而 swagger 编辑器是我们前端的主要部分。
您是否看到开源和平台开发工作之间有大量协作？
从我的角度来看，存在大量的协作。例如，Codegen，我们可能会向开源团队提出问题和/或功能请求，这些问题和/或功能请求可能会或可能不会成为下一个版本的一部分。
我最近依靠开源团队来帮助我快速了解开源标准，包括开发、PR、发布流程、文档等。这是一种学习体验，但也是一种很好的体验！
我们看到许多用户和客户真正开始重视设计优先的开发方法（编写和更新 OAS 以在开发之前计划对服务进行更改）的想法。您对设计优先，或者团队在代码和设计优先之间取得的平衡有什么看法？
在加入 Smartbear 之前，我对 API 开发之前的设计概念并没有太在意。在开发 API 时，我经常会直接跳到我的控制器类，创建或更新端点，并在稍后阶段将更改传达给客户端！我现在看到了设计优先方法的价值，并且会以设计优先的态度对待任何 API。
我们在定义 SwaggerHub 后端和前端之间的通信时使用设计优先原则。我们一起完成工作，以定义需要什么、什么是最佳实践以及什么是可以实现的。一旦定义了 API，它就充当了开发后端和前端的开发人员之间的契约。当遵守该契约时，两者都不会遇到任何无法预料的意外。使用 SwaggerHub 的自动模拟，前端开发人员可以在后端实现之前开始开发，这可以解除阻塞并加速开发。
就像编写代码一样，我认为最好是写一点，测试，重构并重复。完整的解决方案将在此过程中自然而然地演变。任何重构都不会需要完全重写，这会导致重大延误（和伤心！）。
我们最近进行了API 状态调查，其中一个重要发现是微服务如何开始改变组织的开发工作和所产生的服务数量。您认为 OpenAPI/Swagger 工具越来越受欢迎与组织正在进行的“数字化转型”之间存在关联吗？
我确实认为存在关联！我们非常有效地使用了 SwaggerHub。正如我所提到的，我们定义 API 定义并将其存储在 SwaggerHub 中。由于我们有很多 API，将它们集中在一个位置并能够使用像 SwaggerHub 这样美观的 UI 查看它们是很好的。
我们使用 SwaggerHub 与 Codegen 结合，在构建过程中生成 API 客户端。这消除了维护自定义编写客户端的需求，并确保我们的请求与预期匹配。这加快了开发速度，并允许我们编写底层业务逻辑，而不是编写样板客户端逻辑。
我最近开始使用第三方 API。他们的文档使用了 Swagger，这真是一个惊喜，让我可以立即着手构建客户端。我期待着看到 SwaggerHub 在后续版本中的发展，并希望在其中发挥重要作用。在插件方面，我们将继续添加其他 SCM 的支持，并在可能的情况下对其进行改进。
有关 SwaggerHub 构建插件的更多信息，请务必浏览该存储库。
如果您有兴趣了解更多关于 SwaggerHub 平台的信息，或者想与 Swagger 专家讨论迁移事宜，请立即安排通话！