技术领域
[0001] 本
发明涉及计算机
软件分布式架构、异步通信机制、持续集成(CI)、持续部署(CD)、容器化等技术，尤其涉及一种基于异步机制的分布式的CI/CD的实现方法。
背景技术
[0002] 随着计算机软件技术的发展及快速更新换代，CI/CD已被广泛用于快速
迭代、频繁发布的软件研发过程中。许多公司或团队都将其用于自己产品的研发过程中单元测试、集成测试、部署发布等环节，其中大部分都是使用Gitlab、Jenkins等集成工具实现的
单体部署架构，master和worker在同一个(
服务器)
节点上，集成、部署效率低下，有严重的阻塞，只能适应于单团队或少量团队的CI/CD；进一步，也有许多公司或团队对这些集成工具进行了分布式部署，可以有效提高构建效率，但是对于很多公司或团队无疑是提高了运维成本，所以很多团队开始选择将其集成、部署的过程转移到PaaS(平台及服务)平台；对于PaaS平台，很难将Gitlab、Jenkins等工具直接集成到自己的UI中并实现一系列与之关联的功能，实现规模化管理、调度并对外提供服务更是难上加难。
[0003] 因此，需要需要一个分布式、异步通信的CI/CD实现方案，以规模化对外提供CI/CD服务、提高用户
请求响应效率，进一步改善用户体验。
发明内容
[0004] 为了解决以上技术问题，本发明提出了一种基于异步机制的分布式的CI/CD的实现方法，能够在规模化应用于PaaS平台提供CI/CD服务的同时，保证其有很好的执行效率和健壮性，进而改善用户体验。
[0005] 本发明的技术方案是：
[0006] 一种基于异步机制的分布式的CI/CD的实现方法，包括如下步骤：
[0007] S1：与Github、Gitlab集成，建立webhook，在代码变更时或直
接触发重新
构建时，master创建构建任务；
[0008] S2：master直接根据代码分支所处的阶段及服务器负载情况，选择对应的worker发送构建任务；
[0009] S3：worker接收到任务，根据代码分支选择镜像、创建容器、更新代码，进行代码编译、单元测试的持续集成操作，并直接返回任务创建状态以响应master的构建请求；
[0010] S4：持续集成依赖容器化技术，每个构建创建一个容器，并将构建过程按规则输出到日志文件中，然后对日志文件进行读取和更新，并更新构建状态及状态信息到
数据库；
[0011] S5：通过定时任务，将构建的状态及状态信息返回到master并进行存储，借助即时提醒更新功能，实时、动态更新界面UI的构建状态及状态信息；
[0012] S6：构建成功后，根据代码分支所处阶段，借助容器化技术，直接在不同的环境进行部署并发布为可用服务；
[0013] 进一步的，在S1之前包含：创建或选择Github、Gitlab代码仓库，并与PaaS平台项目之间创建webhook，确保在Github、Gitlab代码仓库变化时及时、自动更新PaaS平台项目分支的状态，进而自动触发构建流程；另外，在S1中，用户可以根据自身需求，手动触发构建流程；
[0014] 所述构建流程，包含master选择worker、发送构建任务，worker选择镜像、创建容器、更新代码、单元测试的流程。
[0015] 进一步的，触发构建流程后，master根据任务类型创建构建任务，与其他的待构建或构建中的任务形成任务队列，构建过程中会根据任务的编号(job_id)进行异步回调，更新任务的状态，直至构建结束后删除构建任务；
[0016] 所述任务类型，是指对代码分支对应的容器的不同操作，包含：新建、更新、数据导入、数据回滚、停止、删除；
[0017] 所述任务状态，包含：新建、构建中、异常三种状态，任务出现异常状态时，任务异常信息亦会同时更新。
[0018] 进一步的，master根据分支所处阶段、负载情况等计算、选择合适的worker进行任务分流，并向
选定的worker发送构建任务请求：
[0019] master根据所选worker的不同url地址，对发送请求进行抽象化处理，发送到对应的worker，由对应worker的统一
接口进行接收，并根据不同的任务类型进行不同的操作；
[0020] worker接收到任务后，会根据PaaS平台项目选择对应的镜像开始构建，并将任务创建结果立即返回响应给master，结束master的请求，此时master开始更新构建状态；
[0021] 进一步的，worker上开始构建，拉取镜像、创建数据库及数据库用户，创建容器时根据构建信息更新环境配置，并将更新后的代码映射到容器中，容器与其对应的数据库之间建立连接，编译、运行代码，并根据不同的任务类型生成对应的日志文件，将构建过程中产生的日志输出到日志文件中；
[0022] 所述构建，是指：代码更新之后对其进行编译，并进行单元测试；对于用户的线上环境，平台会自动忽略单元测试，只对测试环境和开发环境进行单元测试，且单元测试的
覆盖程度与容器内代码有关；
[0023] 所述日志文件会在根据每个容器构建信息生成的文件目录中统一进行管理，及每个容器都会有一个单独的文件存放日志文件，构建过程中，用户可以直接在master web UI中根据需要查看全部的日志并根据条件过滤日志.
[0024] 进一步的，worker服务会通过线程机制，对每个容器的日志进行读取、解析，并将构建状态及状态信息更新到worker服务对应的数据库中，直到构建结束或构建时间超时，停止更新状态及状态信息；
[0025] 对于全部构建，会存储在一张数据库表(build)中，在构建过程中，更新build表中的状态及状态信息，还会在另外一张数据库表(build_sync)中创建一行数据，关联新建的build，代表此build处于正在构建过程中；
[0026] worker服务中实现了一个定时任务，定时触发获取当前数据库全部正在构建中的容器，查看容器的状态及状态信息，并向master发送请求，更新将全部正在构建的容器状态及状态信息；
[0027] 进一步地，master接收到worker的更新状态的请求时，按顺序对对应的构建的状态和状态信息进行更新，并返回给worker更新的结果，当worker收到响应之后会对已经更新成功的build_sync中的数据进行删除，直至构建结束；
[0028] 所述直至构建结束，并非worker中定时任务结束，worker提供服务过程中，定时任务会一直运行，构建结束是指当容器构建完成后，将不再更新build表中对应数据的状态及状态信息，也不再在build_sync表中创建新数据，即为构建结束。
[0029] 进一步的，每次master在响应worker更新状态及状态信息的请求之后，会通过即时提醒更新功能，对web UI中的状态及状态信息不断的更新，直到构建结束时状态不再变更；构建结束后会在web UI中展示构建结果；
[0030] 所述即时提醒更新功能，是指基于某一个模型及该模型中的唯一标识(id),更新所需在web UI中展示的字段的值并
渲染更新后的值；
[0031] 所述构建结果，包含：构建成功、构建失败，是指单元测试过程中产生的测试结果，是否为测试通过；对于warning级别的错误，亦视为成功，但会在web UI中显示：Test warning；对于error或exception级别的错误，则视为构建失败，在web UI中会显示对应的错误信息。
[0032] 进一步的，构建成功后，会立即停止并删除构建过程所用容器，根据代码及相关配置构建新的容器镜像，并将镜像保存、发布到镜像仓库；镜像发布后，立即拉取新镜像并部署；
[0033] 平台会对部署后的容器及数据库进行管理，对于production阶段仅保留最新的容器及唯一一个数据库，对于development、staging阶段最多保留最近四次成功部署的容器及其对应的数据库。
[0034] 进一步的，本发明采用分布式部署架构，包括：
[0035] 一台master服务器、一台以上的worker服务器，
[0036] worker服务器分为development、staging、production三类，分别为对应分支阶段提供服务，其中，staging阶段依赖于production，复制线上数据模拟测试环境，提供UAT测试服务；
[0037] 在有新的构建任务时，master会根据PaaS平台项目中触发构建的分支所处的阶段，选择符合分支阶段的worker，并根据服务器的负载情况，选择负载最小的一台worker，发送构建任务请求；
[0038] 所述负载最小，首先，是指每个worker有最大的容器同时构建数限制：为保证worker服务器上已部署成功的容器正常提供服务的能
力，当每个符合分支阶段的worker正在构建中的数量皆达到对其设置的最大值时，会产生任务等待，master上的同样通过任务队列对等待的任务进行管理，当符合条件的worker出现空闲时，重新发送构建任务请求；其次，当有一台以上符合条件的worker出现空闲时，会根据worker的
硬件指标，选择空闲率高的服务器进行分配；
[0039] 所述worker空闲，是指一台worker当前处于正在构建中的任务的数量小于该worker的最大的容器构建数。
[0040] 进一步的，本发明基于异步机制进行通信，包括：
[0041] master创建构建任务后，请求worker执行构建任务，无需等到构建结束即可获得相应：worker收到请求后，同样会执行任务创建，会立即返回任务创建的结果给master，master CI界面开始动态展示构建状态及状态信息；
[0042] worker上构建开始，会将构建过程中产生的日志进行读取并解析，获取构建状态及状态信息，并不断的回调worker中的方法地址，将数据更新到数据库表中进行存储；
[0043] worker上有一个定时任务，定期检查数据库表，获取正在构建中的任务的状态及状态信息，并发送给master，master接到请求后会将数据存储到数据库表中，并更新job的状态，master通过即时提醒更新功能对web UI状态、状态信息数值进行渲染更新。
[0044] 本发明的有益效果是：
[0045] 本发明可以解决当前软件开发快速迭代、频繁发布而面临的难以立即自动集成、测试验证、快速部署的问题，最大化减少人为介入和决策，使研发人员专注于产品打磨，提高代码
质量及交付效率，节约人力成本在机器可以做的很好的情况下的浪费。同时环境标准化，可以避免硬编码的脚本带来后续升级改造成本或者绑架技术栈；流程标准化有助于扩展性提升，连接研发流程的设施可以相对轻松的进行升级维护。另外，通过分布式的CI/CD部署架构，可以有效降低模
块间耦合度，方便其扩展、部署；划分清晰每台服务器的责任，master根据不同的阶段及负载情况选择不同worker，减少每台服务器的负载、提高CI/CD的效率，并提高实现代码的复用性。进一步，通过异步通信机制，减少每次请求通信时长和资源占用、避免阻塞，立即返回初步结果，提高响应效率并可以动态的展示当前CI/CD任务的状态，增强系统健壮性、改善用户体验。同时，可以解决Gitlab、Jenkins等不能规模化为PaaS平台用户提供对外服务的问题。
附图说明
[0046] 图1是分布式部署架构示意图；
[0047] 图2是CI/CD异步实现示意图；
[0048] 图3是master根据阶段及负载情况选择worker并发送任务示意图；
[0049] 图4是worker构建流程示意图；
[0050] 图5是master构建状态更新示意图。
具体实施方式
[0051] 为使本发明
实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例，基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0052] 本发明是通过如下技术方案实现的：
[0053] 第一方面，本发明提供了一种CI/CD的实现方法，包括：
[0054] S1：与Github、Gitlab等集成，建立webhook，在代码变更时(push、merge等)或直接触发重新构建时，master创建构建任务
[0055] S2：master直接根据代码分支所处的阶段(development、staging或production)及服务器负载情况，选择对应的worker发送构建任务；
[0056] S3：worker接收到任务，根据代码分支选择镜像、创建容器、更新代码，进行代码编译、单元测试等持续集成操作，并直接返回任务创建状态以响应master的构建请求；
[0057] S4：持续集成依赖容器化技术，每个构建创建一个容器，并将构建过程按规则输出到日志文件中，然后对日志文件进行读取和更新，并更新构建状态及状态信息到数据库；
[0058] S5：通过定时任务，将构建的状态及状态信息返回到master并进行存储，借助即时提醒更新功能，实时、动态更新界面UI的构建状态及状态信息；
[0059] S6：构建成功后，根据代码分支所处阶段，借助容器化技术，直接在不同的环境进行部署并发布为可用服务；
[0060] 进一步地，在S1之前包含：创建或选择Github、Gitlab等代码仓库，并与PaaS平台项目之间创建webhook，确保在Github、Gitlab等代码仓库变化(代码提交、分支合并、分支创建等)时可以及时、自动更新PaaS平台项目分支的状态，进而自动触发构建等流程，同时，在平台上对项目分支、代码的改动也会直接影响远程Github、Gitlab等仓库；另外，在S1中，用户也可以根据自身需求，手动触发构建流程；
[0061] 所述构建流程，是一个广义上的构建流程，包含但不限于master选择worker、发送构建任务，worker选择镜像、创建容器、更新代码、单元测试等一系列流程；
[0062] 进一步地，触发构建流程后，master根据任务类型创建构建任务，与其他的待构建或构建中的任务形成任务队列，构建过程中会根据任务的编号(job_id)进行异步回调，更新任务的状态，直至构建结束后删除构建任务；
[0063] 所述任务类型，是指对代码分支对应的容器的不同操作，包含：新建、更新、数据导入、数据回滚、停止、删除等；
[0064] 所述任务状态，包含：新建(待构建)、构建中、异常三种状态，任务出现异常状态时，任务异常信息亦会同时更新；
[0065] 进一步地，master根据分支所处阶段、负载情况等计算、选择合适的worker进行任务分流，并向选定的worker发送构建任务请求：master根据所选worker的不同url地址，对发送请求进行抽象化处理，发送到对应的worker，由对应worker的统一接口进行接收，并根据不同的任务类型进行不同的操作；
[0066] 进一步地，worker接收到任务后，会根据PaaS平台项目的类型、版本等选择对应的镜像开始构建，并将任务创建结果立即返回响应给master，结束master的请求，此时master开始更新构建状态；
[0067] 进一步地，worker上开始构建，拉取镜像、创建数据库及数据库用户，创建容器时根据构建信息更新环境配置，并将更新后的代码映射到容器中，容器与其对应的数据库之间建立连接，编译、运行代码，并根据不同的任务类型生成对应的日志文件，将构建过程中产生的日志输出到日志文件中；
[0068] 所述构建，是指：代码更新之后对其进行编译，并进行单元测试；为了避免脏数据的插入，对于用户的线上环境，平台会自动忽略单元测试，只对测试环境和开发环境进行单元测试，且单元测试的覆盖程度与容器内代码有关；
[0069] 所述日志文件会在根据每个容器构建信息生成的文件目录中统一进行管理，及每个容器都会有一个单独的文件存放日志文件，构建过程中，用户可以直接在master web UI中根据需要查看全部的日志并根据条件过滤日志；
[0070] 进一步地，不同项目、不同分支对应的不同容器能同时构建或运行是因为：对于worker服务，对应了多个线程，分别对构建日志进行读取、解析；对于worker服务器，每个容器都是一个单独的
进程，且容器内进程隔离、透明；
[0071] 进一步地，worker服务会通过线程机制，对每个容器的日志进行读取、解析，并将构建状态及状态信息更新到worker服务对应的数据库中，直到构建结束(成功或失败)或构建时间超时，停止更新状态及状态信息；
[0072] 进一步地，对于全部构建，会存储在一张数据库表(build)中，在构建过程中，更新build表中的状态及状态信息，还会在另外一张数据库表(build_sync)中创建一行数据，关联新建的build，代表此build处于正在构建过程中；
[0073] 进一步地，worker服务中实现了一个定时任务，定时触发获取当前数据库全部正在构建中的容器，查看容器的状态及状态信息，并向master发送请求，更新将全部正在构建的容器状态及状态信息；
[0074] 进一步地，master接收到worker的更新状态的请求时，按顺序对对应的构建的状态和状态信息进行更新，并返回给worker更新的结果，当worker收到响应之后会对已经更新成功的build_sync中的数据进行删除，直至构建结束；
[0075] 所述直至构建结束，并非worker中定时任务结束，worker提供服务过程中，定时任务会一直运行，构建结束是指当容器构建完成后，将不再更新build表中对应数据的状态及状态信息，也不再在build_sync表中创建新数据，即为构建结束；
[0076] 进一步地，每次master在响应worker更新状态及状态信息的请求之后，会通过即时提醒更新功能，对web UI中的状态及状态信息不断的更新，直到构建结束时状态不再变更；构建结束后会在web UI中展示构建结果；
[0077] 所述即时提醒更新功能，是指基于某一个模型(数据库表)及该模型中的唯一标识(id),更新所需在web UI中展示的字段的值并渲染更新后的值；
[0078] 所述构建结果，包含：构建成功、构建失败，是指单元测试过程中产生的测试结果，是否为测试通过；对于warning级别的错误，亦视为成功，但会在web UI中显示：Test warning；对于error或exception级别的错误，则视为构建失败，在web UI中会显示对应的错误信息；
[0079] 进一步，构建成功后，会立即停止并删除构建过程所用容器，根据代码及相关配置构建新的容器镜像，并将镜像保存、发布到镜像仓库；镜像发布后，立即拉取新镜像并部署；
[0080] 所述删除构建过程所用容器，是因为系统已根据配置将需要保留的文件目录进行了持久化，并且不会删除数据库，且一个数据库只会对应一个容器服务，另外，对于production阶段，只会更新容器，数据库及持久化的数据不会因为更新丢失；
[0081] 所述部署，并非只部署production阶段，development、staging阶段也会进行部署，这些容器会在不同服务器上、自动生成不同域名、提供不同服务，域名生成与项目名、分支名、构建顺序等信息相关，用户也可以根据需求设置自己的域名，其中，对于production阶段的容器服务不会根据构建(更新)而改变域名的映射；
[0082] 进一步，平台会对部署后的容器及数据库进行管理，对于production阶段仅保留最新的容器及唯一一个数据库，对于development、staging阶段最多可以保留最近四次成功部署的容器及其对应的数据库；
[0083] 第二方面，本发明是采用分布式部署架构，包括：
[0084] 一台master服务器、多台worker服务器，worker服务器分为development、staging、production三类，分别为对应分支阶段提供服务，其中，staging阶段依赖于production，复制线上数据模拟测试环境，提供UAT测试服务；
[0085] 进一步地，在有新的构建任务时，master会根据PaaS平台项目中触发构建的分支所处的阶段，选择符合分支阶段的worker，并根据服务器的负载情况，选择负载最小的一台worker，发送构建任务请求；
[0086] 所述负载最小，首先，是指每个worker有最大的容器同时构建数限制：为保证worker服务器上已部署成功的容器正常提供服务的能力，当每个符合分支阶段的worker正在构建中的数量皆达到对其设置的最大值时，会产生任务等待，master上的同样通过任务队列对等待(即待构建)的任务进行管理，当符合条件的worker出现空闲时，重新发送构建任务请求；其次，当有多台符合条件的worker出现空闲时，会根据worker的CPU、RAM等硬件指标，选择空闲率高的服务器进行分配；
[0087] 所述worker空闲，是指一台worker当前处于正在构建中的任务的数量小于该worker的最大的容器构建数；
[0088] 第三方面，本发明基于异步机制进行通信，包括：
[0089] master创建构建任务后，请求worker执行构建任务，无需等到构建结束即可获得相应：worker收到请求后，同样会执行任务创建，会立即返回任务创建的结果给master，master CI界面开始动态展示构建状态及状态信息；
[0090] 进一步，worker上构建开始，会将构建过程中产生的日志进行读取并解析，获取构建状态及状态信息，并不断的回调worker中的方法地址，将数据更新到数据库表(build、build_sync)中进行存储；
[0091] 进一步，worker上有一个定时任务，定期检查build_sync，获取正在构建中的任务的状态及状态信息，并发送给master，master接到请求后会将数据(包含构建状态、状态信息等)存储到数据库表(build)中，并更新job的状态，master通过即时提醒更新功能对web UI状态、状态信息等数值进行渲染更新。
[0092] 本发明实现了一种CI/CD的方法，可以规模化应用到PaaS平台中，其次，通过分布式的部署架构对其性能进行了改善，保证了系统的健壮性，提高了CI/CD的效率，并且，通过异步的通信机制，动态刷新CI/CD的状态及状态信息，进一步提高了CI/CD效率，具有更好地用户体验效果。
[0093] 本发明通过CI/CD流程可以有效降低软件开发快速迭代、频繁发布过程中的人为介入及决策，提高代码质量及产品交付效率；提供标准化环境和流程，降低改造成本、提高扩展性，进一步有效节约人力、服务器及其运维成本；分布式的部署架构和异步的通信机制，可以进一步提升CI/CD的执行效率、降低资源占用、避免进程阻塞，提高用户请求响应效率，增强系统健壮性并改善用户体验。
[0094] 以上所述仅为本发明的较佳实施例，仅用于说明本发明的技术方案，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所做的任何
修改、等同替换、改进等，均包含在本发明的保护范围内。
