云原生架构下的产品自动化发布、快速部署和持续交付实战之路

1.背景介绍

CI/CD是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一种面向开发和运维团队的解决方案，CI/CD 主要针对在集成新代码时所引发的问题（亦称：“集成地狱”）。CI/CD创建了一个可重复的、可靠的且可预见的发布流程，从而大大缩短了发布周期，不仅节省下了巨大的金钱成本，还节省了包括建立和维护这样一个发布系统所需要的时间投入。

在引入CI/CD技术之前，公司测试人员自动化打包主要依赖实现vue组件之间传值，在配置任务的源码、构建触发器、构建环境、构建、构建后操作等步骤后，可以触发构建任务。相比传统的拉代码、运行命令打包、整理上传更新文件，重启服务等繁琐的操作，任务构建这种方式在一定程度上节省了测试和研发人员的时间。但随着代码仓库数量的日益增长vue组件之间传值，以及在公司内部使用程度越来越深，一些问题也逐渐暴露。例如：

为了解决以上问题，我们使用了 原生 CI/CD 构建框架和基于的声明式持续交付工具Argo CD，并将流水线接入项目管理平台，简化了代码打包步骤、降低了使用人员的学习成本、提供稳定的测试环境、自动粘贴归档文件下载链接、自动创建更新任务等，进一步提高了持续集成的效率。

2. 系统设计

流水线系统设计以项目管理平台为入口，为环境基础，使用完成CI部分功能，在构建完成后更新服务编排文件。Argo CD则负责持续监控应用状态，并更新应用。

2.简介

是一个开源的，用于管理云平台中多个主机上的容器化的应用，的目标是让部署容器化的应用简单并且高效（）,提供了应用部署、规划、更新、维护的一种机制。

一个核心的特点就是能够自主的管理容器来保证云平台中的容器按照用户的期望状态运行着（比如用户想让一直运行，用户不需要关心怎么去做，会自动去监控，然后去重启，新建，总之，让一直提供服务），管理员可以加载一个微型服务，让规划器来找到合适的位置，同时，也系统提升工具以及人性化方面，让用户能够方便的部署自己的应用（就像 ）。

2.简介

是一个基于 的云原生 CI/CD 开源框架，属于 CD 基金会的项目之一。 通过定义 CRD 的方式，让用户以灵活的自定义流水线以满足自身 CI/CD 需求。

最主要的四个概念为：Task、、 以及 。

综上： 由多个 Task 组成，每次执行对应生成一条 ，其控制的 将创建实际运行的 Pod。

2.3Argo CD 简介

Argo CD 是一个为 而生的，遵循声明式 理念的持续部署（CD）工具，它的配置和使用非常简单，并且自带一个简单易用的 页面，并且支持多种配置管理/模板工具（例如 、Helm、、、plain-YAML）。

Argo CD 被实现为一个 控制器，它持续监控应用的实际状态，周期性地拉取 Git 仓库中的配置清单，并将实际状态与期望状态进行比较，如果实际状态不符合期望状态，就会更新应用的实际状态以匹配期望状态。

Argo CD的主要功能：

部署或回滚到 Git 仓库中提交的应用程序的任何状态（这也是使用 Git 进行版本管理的一大好处。

2.4项目管理平台

政通项目管理平台是流水线使用的入口系统，在同步保存仓库、分支、CI/CD参数后，新增流水线任务时将参数传给。流水线任务执行时，会将当前流水线信息推送到项目管理平台。

流水线打包成功后会将归档路径推送到项目管理平台。

新增流水线时如果勾选了创建更新任务，也会在流水线打包成功后自动创建更新任务。

新增流水线时选择运行测试环境，则会通过Argo CD更新测试服务。

流水线运行异常时，会将相关信息推送到项目管理平台，方便排查问题。

3. 流水线的使用

下面以-urban-v14代码为例，介绍流水线打包如何使用。

（1）步骤一：参数配置。

（2）步骤二：同步配置管理–项目管理–同步，同步仓库、分支、变量。代码仓库会在代码提交后自动同步。变量只需要在修改后同步1次即可。

（3）步骤三：新增提测单项目管理平台任务处理完成以后，点击任务右上角“生成提测”功能按钮，从列出的根据提交记录查询的代码仓库和分支列表中，选择需要使用的流水线打包的代码仓库和分支。

（4）步骤四：新增流水线。以上步骤完成后，就来到了最关键最常用的新增流水线环节，在任务界面点击右上角“新增流水线”功能按钮，填写相关信息。

后台会根据提测单自动填充部分内容，如有调整，可手动修改。

参数说明如下：

大部分参数都不需要手动填写，只需要确认无误后点击创建，流水线任务即创建成功，等待流水线自动打包完成即可。打包完成或者因代码问题打包失败会通知操作人。

4. 流水线任务处理流程

我们从流水线的任务处理流程、流水线任务和步骤来说明流水线中的关键技术。

4.1任务接收

流水线任务是通过接收的， 是的一个组件，它可以从各种来源的事件中检测并提取需要信息，然后根据这些信息来运行和，还可以将提取出来的信息传递给它们以满足不同的运行要求。其核心组件如下：

在接收提交的流水线请求时，使用验证请求、解析参数，包含了新增流水线请求的值和根据代码仓库id查询的代码仓库的CI/CD参数，根据参数值启动对应的，如智信h5打包的build–h5或build–h5-npm。

4.2任务执行

通过指定要运行的，中定义了多个Task，每个Task又包含一个或多个Step。 以-urban-v14代码的流水线为例，主要Task及其执行顺序如下：

除了以上流水线打包的任务外，还在部分指定了多个最终任务（ task），无论Tasks部分声明的常规任务执行成功还是报错，最终任务都会在常规任务执行完成后并行执行。

任务的执行顺序是根据来决定的，未声明的任务可以和其他任务并行执行。另外，只有when中声明的条件都满足时任务才会执行，否则会跳过。例如-new–task任务，需要等待归档任务（）完成后才可能执行，并且只有当项目管理平台任务号不为空，且创建流水线任务时勾选了创建更新任务，才会在归档后创建项目管理平台更新任务。

name: redmine-new-update-task  retries: 1  taskRef:    name: redmine  runAfter:    - archive  when:    - input: "$(params.issue_id)"      operator: notin      values: [ "" ]    - input: "$(params.new_update_issue_flag)"      operator: in      values: [ "true" ]

4.3典型任务和步骤

中的任务虽然看起来非常多，但是大部分是可复用的。另外，与中声明的任务不同，Task中声明的步骤（step）是按照声明的顺序依次执行的。我们以典型的任务-为例来说明，任务步骤执行顺序如下：

各个步骤完成的内容为：

-任务的很多额外步骤是为了解决代码代码不规范的问题，例如代码中定义不完整，直接执行maven clean -P ,,…时，往往不能成功。在-步骤中，通过多次循环补充当前依赖的其他。虽然直接修改代码也能解决这个问题，但是由于-urban-v14代码插件非常多，分支也非常多，改起来会相当耗时。并且由于插件之间依赖关系比较复杂，开发过程中难以维持正确的依赖关系定义。

4.4发布更新

由上文任务列表可知，服务更新其实也是包含在任务执行中的。我们借助Argo CD的自动同步和部署应用程序的优势，在打包完成后，制作镜像，并推送到镜像仓库。随后更新Argo CD部署文件代码，触发Argo CD同步，Argo CD检测到部署文件更新后，将自动与K8S交互，更新服务。K8S滚动更新的特性，能够在保证服务不中断的情况下完成升级。

总结起来，流水线的使用流程如下图：

5. 成果和计划

相比传统的打包，流水线的优势在于：

截止目前，流水线平台已归纳支持12种类型的代码结构打包，主要包含了智云主框架、智云前端、智信前端、微服务、智云拆分代码、智信拆分代码等。项目管理平台接入流水线仅半年就完成了打包任务数3987，流水线任务总运行8140次。通过Argo CD管理一网统管、信息采集、城市大脑、基础平台、市政、执法、星桥、灵珑、社会治理、运管服10条产品线，共67套运行环境。

后续计划整合武汉的服务器，全部虚拟化后，将各产品线测试环境全面接入流水线，研发、测试环境隔离互不干扰，做到可按需开启，定时关闭。利用流水线流程的易扩展性，接入单元测试、自动测试流程。

本文到此结束，希望对大家有所帮助。