OpenAPI をすでに利用しているチームは、集中管理された SwaggerHub ソリューションの価値を認識していますが、多数のサービス定義を移行して構成することは、面倒なプロセスに感じられるかもしれません。この数週間、SwaggerHub チームは、このワークフローを簡単に自動化し、チームがプラットフォームに迅速にオンボーディングできるように、オープンソースビルドプラグインに大幅な更新を行いました。
最初の機能は、定義を一括で SwaggerHub に移行する機能です。OpenAPI 定義のディレクトリを解析してプラットフォームにプッシュできるため、新しい集中環境の開始と整理にかかる時間を大幅に短縮できます。
定義をコードに簡単に結び付けるために、プラグインは現在、SCM 統合を自動的に構成し、SwaggerHub に保存されている定義と、ビルド環境の一部として生成およびデプロイされている定義との間に双方向の関係を作成します。定義に変更が加えられると、ビルド中に構成されたリポジトリに自動的にプッシュされます。この機能により、チームは、従来の開発プラクティスで設計優先またはコード優先のどちらであったかにかかわらず、OpenAPI の機能を活用できます。
プラグインとそれに関する作業について詳しく知るために、SwaggerHub のゴールウェイを拠点とする開発者の一人である Michael Melody 氏に、プラグインでの経験、オープンソースと有償開発タスクのバランス、API 開発への設計優先のアプローチに対する彼の見解について話を聞きました。
SwaggerHub チームの一員になってどのくらいになりますか？
2018年の夏に入社しました。ここゴールウェイの開発者として、以前の雇用で SmartBear 製品を使用していたこともあり、SmartBear の存在は常に認識していました。この役職が募集されたとき、私はチームに参加するチャンスに飛びつきました！
あなたの開発経験はどのようなものですか？過去に他のオープンソースプロジェクトに取り組んだことはありますか？
2014年に大学を卒業して以来、プロとして開発に携わって約5年になります。オープンソースでの作業は常に私の野心でしたが、これまで実現したことはありませんでした。 これまでのところ、オープンソースに関わることは良い経験になっています。
プラグインのアップデートは、プラットフォームへの移行を検討している多くの組織を本当に支援するでしょう。変更のための開発作業はどのようなものでしたか？ソロプロジェクトでしたか、それとも複数の開発者がこれに取り組んでいましたか？
プラグインを現在の状態にするために、チーム全体から大きな推進力がありました。プラグインは元々、Smartbear で開催されたハッカソンから生まれました。以前の開発者の一人（John French に感謝 - 彼は退職しましたが、PR を通じて貢献を続けています）が、ビルドプロセスの一部として API 定義を取得できるようにプラグインを考案しました。
最近では、最新のリリースの一環として、私たち数名がこれを完成させ、最高品質であることを確認するために協力しました。設計に関する議論に参加し、プルリクエストをレビューした開発者から、テスト時にプラグインを徹底的に検証した QA まで、多岐にわたります。
チームはざっくりとしたタイムラインに従いましたか？
タイムラインに関しては、プラグインの開発と SwaggerHub バックエンドの変更を、2週間のスプリントを3回に分けて計画しました。v1.0.3 を提供するために必要なものを3つの小さな開発チャンクに分割することで、これを達成できました。
- 複数の定義のアップロード
- SwaggerHub バックエンドの更新が必要
- GitHub 統合のプロビジョニング
振り返ってみると、最初のスプリントの後にプラグインをリリースして、一部の機能をより早く提供できたかもしれません。これは将来の開発で考慮すべき点です。
このプラグインは、Swagger ツールから API テスト用の SoapUI まで、SmartBear がサポートする大規模なオープンソースプロジェクトコレクションの一部です。あなたは通常、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 の現状調査を実施しましたが、その大きな収穫の1つは、マイクロサービスが組織の開発努力と作成されるサービスの数をどのように変え始めているかでした。OpenAPI/Swagger ツールの人気が高まっていることと、組織がこの「デジタルトランスフォーメーション」を経験していることの間には相関関係があると思いますか？
そう思います！私たちは SwaggerHub を非常に効果的に使用しています。前述のとおり、API 定義を定義し、それらを SwaggerHub に保存しています。かなりの数があるため、それらを一箇所に集中させ、SwaggerHub のような優れた UI で表示できるのは良いことです。
ビルドプロセス中に API クライアントを生成するために、SwaggerHub と Codegen を組み合わせて使用しています。これにより、カスタム作成されたクライアントを維持する必要がなくなり、リクエストが期待されるものと一致することが保証されます。これにより開発が加速され、定型的なクライアントロジックを書く代わりに、基礎となるビジネスロジックを書くことができます。
最近、サードパーティ API の操作を始めました。そのドキュメントは Swagger を使用しており、これは嬉しい驚きで、すぐにクライアントの作成に取りかかることができました。今後のリリースで SwaggerHub がどのようなものを用意しているのか楽しみで、それに大きく貢献したいと思っています。プラグインに関しては、引き続き他の SCM のサポートを追加し、可能な限り改善を続けています。
SwaggerHub ビルドプラグインの詳細については、リポジトリをぜひご覧ください。
SwaggerHub プラットフォームについて詳しく知りたい場合や、移行について Swagger の専門家と話したい場合は、今すぐ電話予約をしてください！