已經是 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 這樣美觀的使用者介面來檢視它們是很好的。
我們將 SwaggerHub 與 Codegen 結合使用，以便在建置過程中產生 API 用戶端。這消除了維護自訂撰寫用戶端的需要，並確保我們的請求與預期的相符。這加快了開發速度，並使我們能夠撰寫底層的業務邏輯，而不是撰寫樣板用戶端邏輯。
我最近開始使用第三方 API。他們的文檔使用 Swagger，這是一個令人驚喜的發現，讓我能夠立即開始建立用戶端。我期待看到 SwaggerHub 在後續版本中的發展，並希望在這方面發揮重要作用。關於外掛程式，我們正在繼續新增其他 SCM 的支援，並盡可能地改進它。
如需有關 SwaggerHub Build 外掛程式的更多資訊，請務必瀏覽儲存庫。
如果您有興趣瞭解更多關於 SwaggerHub 平台或與 Swagger 專家討論遷移事宜，請立即安排通話！