了解微服务集成测试的步骤和要求，每个步骤的最佳实践，以及有关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配置服务器之类的外部运行时配置。更好地为配置值提供部署描述符。