了解微服務集成測試的步驟和要求，每個步驟的最佳實踐，以及有關QA環境的提示。

微服務的優勢，例如縮短的開發時間，小的獨立發行版以及分散的治理，帶來了一系列挑戰，例如版本控制、測試、部署和配置控制。

本文可以提供一種方法來處理微服務的復雜構建、測試和部署過程。

問題描述

對于只有少量微服務或常規服務的項目，構建、測試和部署過程非常簡單。通常，這樣的解決方案具有兩個或三個帶有服務和UI的Docker映像，因此很容易執行集成和測試，并得出服務相互之間以及與UI兼容的結論。版本控制策略也可以很簡單。程序集（pom，nuget或其他）文件的版本。對于每個微服務，甚至可以手動部署到登臺或生產環境。

當以下情況發生時，

• 該解決方案分為幾個獨立的“流”，每個“流”都有一組微服務和UI。
• 每個微服務都有其生命周期和發布周期。
• 不同（甚至是競爭）的團隊在項目上工作。
• 來自一個“流”的微服務對另一個“流”的微服務具有運行時依賴性。
• 微服務取決于生態系統（一組常用服務，如AAA，日志記錄等）。

當每個微服務在每個環境中都有自己的部署和運行時配置時，情況變得更加復雜，例如，無需在測試環境中安裝微服務的多個實例，但是生產需要它。結果，我們至少需要處理以下3維數組：

• 容器化微服務Docker/LXC/OS映像，
• 部署配置，以及
• 運行時配置

需要對其進行管理。

此外，項目中可能還存在一些其他約束和要求。我們需要考慮的一些其他要求：

• 不變的服務器范例。
• 未經測試的微服務不得出現在存儲庫中。
• 每個通過測試程序的內部版本都可以交付。
• 整個解決方案的部署/回退過程應盡可能簡單，并避免處理所有具有不同版本的不同微服務的復雜性。

建造程序

一種微服務的管道

當世界其他地區關閉時，微服務必須繼續工作，因此以下結果是正確的-必須首先單獨構建和測試。一種微服務的管道將類似于以下所示。

步驟：

1. 將代碼更改合并到SCM的master/build分支中將觸發構建過程。
2. 在構建過程中執行單元和組件測試。還執行靜態代碼分析以通過源代碼質量門。
3. 將構建工件發布到臨時存儲庫中。
4. 從模板創建臨時部署描述符。對于Jenkins，可以使用Velocity，Groovy或任何其他模板。
5. 部署到開發環境中，僅允許對開發人員進行手動檢查，而無需考慮集成測試結果。
6. 部署到測試環境并開始集成測試。擁有外部化的測試場景和過程真是太好了。
7. 如果集成測試通過，則發布到存儲庫中。觸發與其他微服務的集成。

端到端測試管道

在此階段，一組微服務將與其他微服務的最新穩定版本集成。

步驟：

1. 下游構建發送已更改的微服務的名稱和版本。
2. 構建服務器將加載所有現有微服務的最新版本號。簡單的屬性文件就足夠了。
3. 將版本與新版本合并。版本集和部署模板用于創建部署描述符。
4. 使用具有一組已更改版本的部署描述符來部署微服務，并運行集成測試。
5. 如果測試過程通過，則構建服務器會將微服務版本集保留為“集成測試前端”，以供下次使用。
6. 編寫配置并發布。為了簡化部署過程，創建一個“超級”部署描述符是有意義的，該描述符將包括所有必要的微服務、配置變量等。

集成測試前

端到端集成測試作業具有所有微服務的最新版本，這些微服務已成功通過集成測試。“集成測試前線”加上更改給出了必須測試的一組微服務版本。

跨所有微服務的集成測試使我們可以說，通過集成測試的每個內部版本都可以交付。

提示和技巧

• 使用“最新”反模式部署服務不是一個好主意，并且您需要指定微服務的確切版本，因為并非所有服務都已更改且需要重新部署。
• 幾乎不可能針對每種環境測試微服務版本的所有可能配置，實際上在大多數情況下并不需要。
• 最好每次都重新創建測試環境。
• 將Jenkins管道保留為源代碼的一部分。
• 嘗試避免使用諸如Spring Cloud配置服務器之類的外部運行時配置。更好地為配置值提供部署描述符。