已经使用 OpenAPI 的团队认识到集中式 SwaggerHub 解决方案的价值，但迁移和配置大量服务定义可能是一个繁琐的过程。在过去的几周里，SwaggerHub 团队对开源构建插件进行了重大更新，以轻松自动化此工作流程，并使团队能够更快地使用该平台。
第一个功能是能够将定义批量迁移到 SwaggerHub。OpenAPI 定义目录可以被解析并推送到平台，大大减少了开始使用和组织新的集中式环境所需的时间。
为了更容易地将定义与代码关联起来，该插件现在会自动配置一个 SCM 集成，以在存储在 SwaggerHub 中的定义与作为构建环境一部分生成和部署的定义之间创建双向关系。当对定义进行更改时，它们会自动推送到构建期间配置的存储库。无论团队在开发实践中是传统的设计优先还是代码优先，此功能都允许他们利用 OpenAPI 的强大功能。
为了了解更多关于该插件及其相关工作，我们采访了 SwaggerHub 位于戈尔韦的开发者 Michael Melody，了解了他开发该插件的经验、如何平衡开源和付费开发任务，以及他对 API 开发中设计优先方法的看法。
您加入 SwaggerHub 团队多久了？
我于 2018 年夏天加入。作为一名在戈尔韦的开发者，并且在之前的工作中使用过 SmartBear 的产品，我一直都知道 SmartBear 在这座城市的存在。当这个职位出现时，我抓住了机会加入了团队！
您的开发背景是什么？您过去参与过其他开源项目吗？
自 2014 年大学毕业以来，我从事专业开发工作已有近 5 年。参与开源一直是我的一项抱负，但我从未真正付诸实践。 到目前为止，参与开源是一个很好的经历。
插件的更新将真正赋能许多希望迁移到该平台的组织——这些更改的开发工作量如何？是个人项目，还是一个开发团队在进行这项工作？
整个团队都大力推动，才使插件达到今天的状态。该插件最初诞生于 Smartbear 举办的一次黑客马拉松。我们之前的一位开发者（向 John French 致敬——尽管他离开了我们，但他仍通过 PR 继续贡献）设计了这个插件，使我们能够将 API 定义作为构建过程的一部分获取。
最近，作为最新版本的一部分，我们有许多人致力于完成这项工作并确保其质量最高；从参与设计讨论和评审拉取请求的开发者，到在测试时全面测试插件的质量保证人员。
团队遵循了大致的时间表吗？
在时间线方面，我们计划在我们的三个为期两周的冲刺中开发插件并对 SwaggerHub 后端进行更改。我们通过将交付 v1.0.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 的 Auto-mock 功能，前端开发者可以在后端实现之前就开始开发，这解除了阻塞并加快了开发速度。
就像编写代码一样，我觉得最好是先写一点，然后测试、重构，再重复这个过程。完整的解决方案将在这个过程中自然演进。任何重构都不会需要彻底重写，这会造成重大的延迟（和痛苦！）。
我们最近进行了 API 现状调查，其中一个重要发现是微服务如何开始改变组织的开发工作以及正在生产的服务数量。您认为 OpenAPI/Swagger 工具日益普及与组织正在经历的“数字化转型”之间存在关联吗？
我认为是！我们非常有效地使用了 SwaggerHub。正如我所说，我们定义了 API 定义并将其存储在 SwaggerHub 中。由于我们有相当多的定义，将它们集中在一个位置并通过像 SwaggerHub 这样美观的用户界面查看它们，这很好。
我们在构建过程中将 SwaggerHub 与 Codegen 结合使用，以生成 API 客户端。这消除了维护自定义编写的客户端的需要，并确保我们的请求与预期匹配。这加快了开发速度，并允许我们编写底层业务逻辑，而不是编写样板客户端逻辑。
我最近开始使用第三方 API。他们的文档使用了 Swagger，这让我感到惊喜，并让我能够立即开始构建客户端。我期待着看到 SwaggerHub 在后续版本中会带来什么，并希望能在这方面发挥重要作用。至于插件，我们将继续添加对其他 SCM 的支持，并尽可能地改进它。
有关 SwaggerHub 构建插件的更多信息 – 请务必探索此仓库。
如果您有兴趣了解更多关于 SwaggerHub 平台或与 Swagger 专家讨论迁移事宜，立即安排通话！