了解微服务集成测试的步骤和要求，每个步骤的最佳实践，以及有关QA环境的提示。
了解微服务集成测试的步骤和要求，每个步骤的最佳实践，以及有关QA环境的提示。
微服务的优势，例如缩短的开发时间，小的独立发行版以及分散的治理，带来了一系列挑战，例如版本控制、测试、部署和配置控制。
本文可以提供一种方法来处理微服务的复杂构建、测试和部署过程。
问题描述
对于只有少量微服务或常规服务的项目，构建、测试和部署过程非常简单。通常，这样的解决方案具有两个或三个带有服务和UI的Docker映像，因此很容易执行集成和测试，并得出服务相互之间以及与UI兼容的结论。版本控制策略也可以很简单。程序集（pom，nuget或其他）文件的版本。对于每个微服务，甚至可以手动部署到登台或生产环境。
当以下情况发生时，
- 该解决方案分为几个独立的“流”，每个“流”都有一组微服务和UI。
- 每个微服务都有其生命周期和发布周期。
- 不同（甚至是竞争）的团队在项目上工作。
- 来自一个“流”的微服务对另一个“流”的微服务具有运行时依赖性。
- 微服务取决于生态系统（一组常用服务，如AAA，日志记录等）。
当每个微服务在每个环境中都有自己的部署和运行时配置时，情况变得更加复杂，例如，无需在测试环境中安装微服务的多个实例，但是生产需要它。结果，我们至少需要处理以下3维数组：
- 容器化微服务Docker/LXC/OS映像，
- 部署配置，以及
- 运行时配置
需要对其进行管理。
此外，项目中可能还存在一些其他约束和要求。我们需要考虑的一些其他要求：
- 不变的服务器范例。
- 未经测试的微服务不得出现在存储库中。
- 每个通过测试程序的内部版本都可以交付。
- 整个解决方案的部署/回退过程应尽可能简单，并避免处理所有具有不同版本的不同微服务的复杂性。
建造程序
一种微服务的管道
当世界其他地区关闭时，微服务必须继续工作，因此以下结果是正确的–必须首先单独构建和测试。一种微服务的管道将类似于以下所示。
步骤：
- 将代码更改合并到SCM的master/build分支中将触发构建过程。
- 在构建过程中执行单元和组件测试。还执行静态代码分析以通过源代码质量门。
- 将构建工件发布到临时存储库中。
- 从模板创建临时部署描述符。对于Jenkins，可以使用Velocity，Groovy或任何其他模板。
- 部署到开发环境中，仅允许对开发人员进行手动检查，而无需考虑集成测试结果。
- 部署到测试环境并开始集成测试。拥有外部化的测试场景和过程真是太好了。
- 如果集成测试通过，则发布到存储库中。触发与其他微服务的集成。
端到端测试管道
在此阶段，一组微服务将与其他微服务的最新稳定版本集成。
步骤：
- 下游构建发送已更改的微服务的名称和版本。
- 构建服务器将加载所有现有微服务的最新版本号。简单的属性文件就足够了。
- 将版本与新版本合并。版本集和部署模板用于创建部署描述符。
- 使用具有一组已更改版本的部署描述符来部署微服务，并运行集成测试。
- 如果测试过程通过，则构建服务器会将微服务版本集保留为“集成测试前端”，以供下次使用。
- 编写配置并发布。为了简化部署过程，创建一个“超级”部署描述符是有意义的，该描述符将包括所有必要的微服务、配置变量等。
集成测试前
端到端集成测试作业具有所有微服务的最新版本，这些微服务已成功通过集成测试。“集成测试前线”加上更改给出了必须测试的一组微服务版本。
跨所有微服务的集成测试使我们可以说，通过集成测试的每个内部版本都可以交付。
提示和技巧
- 使用“最新”反模式部署服务不是一个好主意，并且您需要指定微服务的确切版本，因为并非所有服务都已更改且需要重新部署。
- 几乎不可能针对每种环境测试微服务版本的所有可能配置，实际上在大多数情况下并不需要。
- 最好每次都重新创建测试环境。
- 将Jenkins管道保留为源代码的一部分。
- 尝试避免使用诸如Spring Cloud配置服务器之类的外部运行时配置。更好地为配置值提供部署描述符。
标签：
来源：慧都
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！