微服务的许多优点，例如减少开发时间、小型和独立发布、分散管理等，带来了一系列挑战，例如版本控制、测试、部署和配置管理。本文提供了一种方法来处理微服务复杂的构建、测试和部署过程。问题陈述对于微服务和普通服务很少的项目，构建、测试和部署过程非常简单。通常，一个解决方案有2-3个Docker镜像、服务和UI，所以很容易进行集成、测试，我们由此得出结论——服务与UI等兼容。版本控制策略也可以很简单，直接使用程序文件（pom、nuget或其他）的版本。即使在部署到生产环境时，也可以为每个微服务手动完成。在以下情况下情况会发生巨大变化：解决方案被分成几个独立的“流程”，每个流程都有一组微服务和UI。每个微服务都有自己的生命周期和发布周期。不同的团队（甚至是竞争关系）在同一个项目上工作。从一个“数据流”运行的微服务依赖于来自另一个“数据流”的微服务。微服务依赖于生态系统（常用服务，如AAA、日志记录等）。当每个微服务都有自己的部署和运行配置时，事情会变得更加复杂。例如，在测试环境中，微服务的多个实例不需要安装，但在生产环境中需要安装。所以我们至少需要处理3-n维数组：容器化微服务Docker/LXC/OS镜像部署配置运行配置这些也需要管理。此外，项目中可能还有一些额外的约束和要求。我们还需要考虑一些额外的要求：不变的服务器范式。资源中不得出现未经测试的微服务。通过测试程序的每个构建都可能是可交付的。整个解决方案的部署/回滚过程应该尽可能简单，而不需要处理不同微服务的复杂性，所有微服务都有不同的版本。构建程序微服务流水线当世界其他地方休息时，微服务必须继续工作，所以下面的结果是正确的——首先它必须单独构建和测试。微服务的管道应该类似于下图。步骤：将代码更改合并到SCM中的master/build分支，这将触发构建过程。在程序构建期间，执行单元测试和组件测试。还可以执行静态代码分析以通过源代码质量检查。将构建工件发布到暂存存储库。从模板创建临时部署描述符。Velocity、Groovy或任何其他模板都可用于Jenkins。部署到开发环境允许开发人员手动检查而不考虑集成测试结果。部署到测试环境，开始集成测试。最好有外部化的测试场景和程序。当案例集成测试通过时发布到存储库。触发与其他微服务的集成。端到端测试管道在此阶段，一组微服务将与其他微服务的最新稳定版本集成。步骤：下游构建发送已更改的微服务的名称和版本。构建服务器加载所有现有微服务的最新版本号。一个简单的属性文件就足够了。与新版本合并。发布和部署模板的集合用于创建部署描述符。使用一组版本化的部署描述符部署微服务并运行集成测试。如果测试过程通过，构建服务器会保留一组微服务，版本化为“pre-integration-test”，供下次使用。组合配置和发布。为了简化部署过程，创建一个“超级”部署描述符，其中将包括所有必要的微服务、配置变量等。集成测试前端到端集成测试作业具有已成功通过集成测试的所有微服务的最新版本。“集成测试之前”加上更改将提供必须测试的微服务版本集。所有微服务的集成测试，可以说是对每一个通过集成测试的构建都进行了交付。Tipsandgotchas使用“***”反模式来部署服务并不是一个好主意，你需要指定微服务的确切版本，因为并不是所有的服务变更都需要重新部署。几乎不可能为每个环境测试所有可能的微服务版本配置，而且在大多数情况下实际上并不需要。***每次都会重新创建测试环境。将Jenkins管道保留为源代码的一部分。尽量避免使用外部运行时配置，例如SpringCloud配置服务器。***使用部署描述符提供配置值。
