在上篇《研发协同平台持续集成实践》一文中我们分享了为什么要做持续集成，技术选型，工作原理以及实践落地。今天我们从架构上来分享一下架构层面的设计和演进。

持续集成1.0

在最开始设计的过程中，本着一切从需求出发，一切以实现业务为原则，我们对主要的业务需求进行了梳理：

• 开发人员希望能快速交付需求

• 测试人员希望在开发人员完成开发后，能够快速根据新的代码集构建独立的环境进行测试验证

• 不同需求的交付互不影响

• 为ERP产品服务

• 一个ERP站点，一个数据库

对上述需求进行整理和挖掘后，我们在设计上整理出以下几点：

• 一个需求，创建一个新的分支进行开发交付，以需求为最小单元进行交付。

• 一个分支，构建一个独立的ERP站点进行测试，这里一个ERP站点就是一个测试环境。

• 一个ERP站点，对应一个独立的数据库

• 需求、分支、ERP站点、数据库是一一对应的关系

在业务上以需求为出发点，在使用上以分支为操作单元，这样做的优点是：

• 用户使用便捷：

• • 创建分支，绑定需求

  • 拉取分支代码开发、自测

  • 提交分支，以分支为单元构建环境测试

• 能快速实现，进行发布验证

在上面的设计中，以分支出发来构建站点，那么一个ERP站点包含什么，如何构建以及销毁呢？

ERP站点组成- 一个可运行ERP站点包括站点程序集、配置和数据库

站点程序集- 通过代码仓库中的分支代码编译产生

配置- 包括本地开发默认配置、测试环境默认配置和自定义配置。默认配置从代码仓库模板中来；自定义配置，按照约定放在代码仓库中的自定义配置目录下，由用户自行选择配置目录来确定。

数据库- 在创建分支时，创建数据库，从最新测试基准库还原而来，基准库每天会定时备份

站点构建

站点销毁

在需求交付以后，平台会自动销毁需求对应的开发分支，同时也会销毁分支对应的ERP站点。

• 销毁构建记录

• 销毁站点容器

• 销毁对应的数据库

持续集成1.x

持续集成1.0版本在上线以后，可以覆盖核心业务场景，但是随着应用的深入，场景也越来越多，其中两个主要需求场景是：

• 需求测试除了ERP站点，还依赖其它服务：

• • ERP系统中的文档上传，浏览等功能依赖文档服务

  • ERP系统中的审批相关功能依赖工作流服务

  • ERP系统和其他系统之间的集成依赖集成服务

• 1.0版本一个分支只能构建一个站点， 这一些场景下需要从一个代码分支构建出多个站点，做不同需求的测试

上面的两个需求中，出现了两个比较大的变化：

• 一个完整的测试环境，不单单包含一个ERP站点，还包括其他应用服务。这打破原有的一个站点，一个环境的设计

• 一个代码分支，可构建出多个对应的站点（多个环境），这打破原有的的一个分支一个站点的设计

这时的需求，原有的设计本质上已不能满足，有两个核心要素缺失：

• 原有的设计是构建一个ERP站点，但更合理的是要构建一个可供测试的环境，这个环境可以只包括一个ERP站点，也可以包括其他的应用服务

• 原有的设计师一个分支构建一个站点（一个环境），但合理的是环境应该可灵活定义。一个环境即可以从一个分支构建而来，也可以从多个分支构建而来。多个不同的环境也可以从相同的分支构建而来。

按照更加合理的设计，在构建的架构设计上是需要做比较大的改动的。但是基于当时正在做持续集成1.0的推广，一旦进行大的改动，影响面比较大。综合评估影响面，资源方面的因素，最终决定不对架构做重构，只在功能上实现做改进来实现需求。
进一步分析新的需求场景：

• ERP站点锁依赖的服务，是都为ERP系统功能服务的，我们定义它们为配套服务。并且这些配套服务（文档服务、工作流服务、集成服务）都是现有的直接可运行的服务，并不需要从代码构建而来。所以可以直接准备好可运行的服务镜像，启动容器即可。不过这里有两个需要注意的点是：

1. ERP的版本和服务镜像的版本是有匹配关系的，并不能完全做到向下兼容

2. ERP所依赖的这些应用服务和ERP耦合都还比较紧，在这些应用服务部署完成后，还需要修改ERP的配置，这里包括文件配置和数据库配置都要做调整

• 针对一个分支构建多个环境的需求，我们当时的策略是克隆分支，再从克隆分支上部署一个站点（环境）

• 针对上述需求，重点是要实现配套服务的持续构建。那么配套服务包含什么，如何构建和销毁呢？

  配套服务的组成-配套服务包括服务容器镜像和配置服务镜像- 由相应的服务团队提供可运行程序集，研发系统平台团队依此构建服务镜像以及维护服务镜像和ERP版本之间的关系

  配置-在ERP系统的配置文件和数据库中，添加相应的配套服务配置信息。在配置服务中，添加ERP系统配置信息

  配套服务构建

  

  配套服务销毁

  在删除配套服务时，会销毁配套服务：

  • 销毁配套服务容器

  • 删除ERP系统中的配套服务配置信息

  持续集成2.0

  持续集成1.x版本在功能上已能很好的满足用户需求，但是随着ERP2.0的发布，ERP产品提供了更加灵活的部署架构来支撑万亿级客户。主要包括集中部署不分库，分离部署分库和分离部署不分库。

  • 分离部署 - ERP的各个子系统分开部署为各个独立的子站点

  • 集中部署 - 所有的ERP子系统部署在一起，一个ERP站点

  • 分库 - ERP的各子系统独立使用各自的数据库

  • 不分库 - ERP的子系统都使用一个数据库

  • 集中部署不分库：ERP（包含售楼、成本、计划系统）部署在一起，一个站点，使用一个数据库

  

  • 分离部署分库：售楼系统部署为主站，成本系统和计划系统部署为从站。主站使用一个数据库，从站使用另外一个数据库

  

  • 分离部署不分库：售楼系统部署为主站，成本系统和计划系统部署为从站。主站和从站都使用同一个数据库

  

  客户如果是分离部署，这就要求原有的ERP产品开发必须拆分成各个子系统，因为各个子系统的系统是分离的，它们的需求需要分开独立交付。尽管在开发模式上各个子系统是独立的，但ERP系统作为一个完整的产品，各子系统之间是需要频繁的集成在一起测试的。并且在分库的场景下，一个环境也不在只对应一个数据库。

  • 分离部署 - 要求一个环境包含多个站点（服务）

  • 集中部署 - 要求一个站点（服务）可以从多个代码分支构建

  • 分库 - 要求一个环境可同时使用多个数据库
    针对上述支撑ERP2.0产品持续集成新的需求，结合1.X中配套服务的实现，我们对持续集成的整体架构设计做了重构

  

  • 环境 - 一切以环境为核心，在持续集成中我们要构建的是可用的、针对不同用途的测试环境。环境可随时新增、删除，也可灵活配置。这样，用户可以随时新增、配置、构建一个用户想要的环境。

  • 服务 - 一个测试环境由一个或多个服务组成，ERP站点是一个服务，文档服务也是一个服务，工作流还是一个服务。环境中的服务可灵活新增、配置、删除

  • 数据库 - 数据库独立创建、删除，不再和分支绑定。在环境中灵活配置要使用的数据库，可配置一个或多个

  • 持续集成管道 - 一种服务类型对应一个持续集成管道，ERP站点可定义自己的持续集成管道，工作流服务也可以定义自己的持续集成管道。每个持续集成管道由不同的作业组成。

  • 作业 - 不同的作业相互组合构建成一个持续集成管道。一个作业又由不同的命令组合而成

  • 命令 - 命令是持续集成过程的最小执行单元。研发协同平台定义了一批默认的命令集。不同命令可组合成不同功能的作业。
    重构后，环境、服务、数据库即互相独立，又可以通过灵活的组合不同的服务和数据库来构建不同的环境，经过2.0的重构后，平台已经能全场景支撑用户的持续集成需求了。

  写在最后

  虽然当前的设计已经能很好的支撑当前的用户持续集成需求，但是ERP2.0产品还在不断进化，进化则带来更多的变化，协同平台也在持续支撑和改进，架构上也要持续的进行优化演进。

  ------ END ------

  作者简介

  陆同学： 架构师，负责研发协同平台产品的架构规划与设计工作。

  也许您还想看

  研发协同平台持续集成实践

  如何解决大批量数据保存的性能问题

  【复杂系统迁移 .NET Core平台系列】之界面层

  【复杂系统迁移 .NET Core平台系列】之迁移项目工程