（作者：SmartBear的ReadyAPI項目高級產品營銷經理）

隨著我們多合一的協作式API質量平臺ReadyAPI v3.3.0的發布，SmartBear的團隊完成了經過重新思考的Git工作流程的第一輪工作——所有這些工作均可直接在工具中使用。

在談論ReadyAPI中對Git支持的改進時，我們很早就意識到，當務之急是我們必須退后一步，圍繞克服的障礙重新構建現有的集成。特別是對于挑戰，用戶在作為小型或大型團隊的一部分來構建項目時會面對。

在Git的支持下，我們邁出了重要的一步，并且在此過程中我們學到了很多。我很高興與您分享這一旅程和我們的課程，因為我們將研究如何（以及為什么）在ReadyAPI中重建Git工作流以適應當今開發團隊的需求。

團隊與測試

我們很幸運能夠與擔當許多不同角色，承擔不同職責，進而對我們的應用有不同期望的用戶緊密合作。我們也很幸運，我們的工具是應用廣泛的，從金融和醫療保健等受到嚴格監管的行業到更靈活的技術組織。總是能看到團隊所面臨的挑戰有多么普遍。

努力以更高的速度構建和交付高質量的應用程序時，無論正在從事的項目，團隊的成員或組織所從事的行業都無關緊要。一些挑戰是普遍存在的，特別是在日益分散的勞動力中。

全球范圍內都在推動我們共同邁向新技術和交付策略。許多組織正處于數字化轉型的過程中：努力將傳統應用程序轉向更精簡、更靈活的小型服務網絡。

我們看到來自這些較小服務的團隊，為他們提供了更大的靈活性，可以使用適用于他們的技術來更改其應用程序。

它使他們能夠按自己的節奏發布，并反過來根據他們的應用程序合作伙伴和使用者接受反饋并關注更新。這種調整以及它們不斷發展的工作方式，反映了技術領域的共同目標——更快地響應不斷變化的消費者需求并應對未來的部署挑戰。

團隊合作和協作是實現這種轉變的重要組成部分。有無數的服務（Slack，Bitbucket是我們的客戶很喜歡的兩個附加工具），其目的是實現更緊密的溝通并幫助管理有關團隊如何合作的流程。

ReadyAPI團隊認識到我們需要成為堆棧的一部分，并以使我們的平臺提高質量和流程的方式實現協作。我們不能成為瓶頸，沒有測試應用程序可以生存。

團隊的外表或工作方式絕非曲折。因此，我們認識到，為了使我們的應用程序能夠滿足最廣泛的需求，我們需要專注于團隊面臨的更廣泛的挑戰，而不是將我們的測試構建工具與存儲和管理測試的地方配對。

改善工具中的完整工作流程不僅可以幫助團隊克服當前的挑戰，還可以使他們發現新的合作方式。

連接性

改善Git支持的第一個機會是我們與提供存儲庫管理服務的平臺和服務的連接。這些共享平臺對團隊流程至關重要，在許多情況下，這些平臺是自動化流程尋找CI/CD任務的最新項目更新的地方。

該團隊建立了一個名為“帳戶管理”的新身份驗證過程，該過程使用戶可以輸入憑據并將其存儲在應用程序級別。這樣，它們可以輕松地在與遠程提供商的交互中重復使用。

這可以采取以下方式：檢索存儲庫列表，簡單地推送更改或打開提取請求，而無需每次都重新輸入認證值。

重用和維護與遠程提供者的連接的能力為后續更新中的功能奠定了基礎，并且為我們使用共享憑證定義了應用程序級空間。

相互作用

用戶體驗是任何應用程序都至關重要的方面，但對ReadyAPI來說尤其重要，因為它提供了范圍廣泛的功能、可擴展性和靈活性。

用戶使用存儲庫的體驗是我們的主要重點，并且看到了更新的Git對話框的發布，該對話框將所有存儲庫的交互都放在一個地方。

通過將這些操作置于中心位置——在項目中發生更改時更新對話框，提供新功能以啟用更完整的Git工作流（例如創建新分支的功能或使用ReadyAPI打開拉取請求的功能）–我們相信 用戶將更輕松地將Git交互作為日常工作流程的一部分，并更清楚地了解他們正在處理的項目中的更改與其對團隊其他成員的影響之間的關系。

沖突管理

無論團隊大小，使用Git工作流程中最常見的挑戰之一就是要徹底解決變更沖突。因此，我們引入了全新的“合并沖突”對話框。

在較高的級別上，它顯示了三個項目-當前正在工作的本地版本，即將進行更改的遠程版本以及解決沖突后將使用的結果項目。

通過分離這些視圖，用戶可以準確查看項目中存在沖突的位置。只是現在，它的外觀風格與我們導航員的項目樹相匹配，并允許用戶做出更明智的沖突決定。

在通過并選擇解決方案之后，可以將這些解決方案作為批處理應用，并且可以更新項目以滿足用戶的決策。

最佳實踐

為了使我們的Git交互和工作流程盡可能靈活，我們付出了巨大的努力。我們相信以下最佳實踐將幫助團隊在使用版本控制和ReadyAPI時創建最佳工作流程，同時為其他希望在其測試工具中構建類似功能的人員提供指導：

分離測試和代碼

一些將開發和測試更加緊密集成的團隊希望將代碼和測試整合到一個存儲庫中，這可能有助于簡化這些資產的“移動”，并使應用程序更改與測試更改保持一致。

但這確實限制了測試資產遵循其自身生命周期并從代碼存儲庫中脫離出來的能力。我們相信，通過將項目存儲在其資源庫中，我們不僅可以通過ReadyAPI中的集成來啟用工作流，而且可以圍繞測試創建、重用和版本控制啟動一個獨立的過程。

利用分支

在使用應用程序代碼時，分支策略是司空見慣的，但是在談論測試資產時，在許多情況下卻忽略了分支策略。隨著項目團隊成員的成長，確定如何進行變更以及將變更匯總在一起的策略至關重要。如果用戶在單個分支上一起工作，則每個小的更改都會立即對其他人的工作產生影響。

這會產生不必要的噪音和不必要的沖突，在許多情況下，可以通過“最終確定”變更來解決。通過跨獨立的分支機構工作，并利用推/拉工作流程和合并功能，團隊可以更無縫地一起處理獨立但相關的任務。

定義拉取請求策略

測試更改的許多要求是實施任務完成定義的一部分。在分支工作流程中，將更改合并到更大的主分支中的能力是共享工作的倒數第二個步驟。拉取請求是在更新進行之前驗證更改和共享調整的機會。

他們還是手動操作的一個很好的步驟-有機會在不參與實際測試創建過程的情況下就決策進行協作-而在較小的項目中，使工作流程的這一階段自動化可以加快較大的交付過程。了解使用手動或自動拉動請求工作流程的好處和取舍，以及探索組合策略的好處非常重要。

SmartBear的團隊希望幫助團隊構建最高質量的軟件，并推動測試創建效率的提高。

我們一直在尋求有關如何幫助改善您的團隊流程的建議，我們熱愛我們的用戶和廣大的開發社區，以提供可解決實際挑戰的API測試平臺。

因此，如果您有任何其他建議或反饋，請告訴我們！

——祝測試愉快！

（作者：SmartBear的ReadyAPI項目高級產品營銷經理）