共计 2099 个字符，预计需要花费 6 分钟才能阅读完成。
今年一直在公司实践 CI，本文将近半年来的一些实践总结一下，可能不太完善或优美，但的确初步解决了我目前所在项目组的一些痛点。当然这仅是一家之言也不够完整，后续还会深入实践和引入 Kubernetes 进行容器编排，以及通过阿里云 K8S 服务进行高效的云上托管，希望对各位童鞋有一点用。
一、持续集成全流程介绍
今年一直在开发我司的一个核心业务系统，一个还未上线的产品开发阶段，其中后端采用 ASP.NET Core + 一系列开源组件开发微服务并且部署在 Linux Docker 中，前端采用 React + Flutter 开发 Web 和 App。采用了 Jenkins 作为 CI 工具，继承了一堆插件 Plugin 实现了初步的持续集成全流程。
下图就是我最近整理的一个目前的持续集成全流程图：
可以看出，在开发测试环境我有 3 个环境：
（1）DEV 环境：用于 dev 分支的前后端开发联调，有单独的数据库
（2）MT 环境：用于 release 分支（现阶段我直接用的 master 分支，产品上线后不可取）的测试进行集成测试，有单独的数据库
（3）DEV-AT 环境：用于 dev 分支的自动化接口测试环境，即专门拿来跑自动化接口脚本的环境，有单独的数据库
针对 CI 服务器，在开发测试环境我有个 2 个节点：
（1）master 节点：用于持续集成和部署等一般性构建任务
（2）slave-at 节点：专门用于跑自动化接口测试脚本构建任务
推荐在 Jenkins 中为不同类型的构建任务设置不同的 label，这样可以绑定不同类型的构建任务至不同的 Node 上执行，从而减少高峰时期 master 节点的负载压力。
二、ASP.NET Core CI 流程部分
我的后端微服务是基于 ASP.NET Core 开发的，采用了容器化部署至 Linux 服务器，之前有过一篇详细的文章介绍过《基于 Jenkins Pipeline 的 ASP.NET Core 持续集成实践》。
在 Jenkins 中提供了 Pipeline 方便地进行构建流水线，在我的实践中主要是通过开发人员的每一次 Check-In 到 git，触发一个 Webhook 到 Jenkins 中从而使持续集成构建任务开始执行：
从图中可以看出，其经历了中台微服务的编译和单元测试 及 BFF（Backend for Frontend）服务的编译和单元测试来保障代码质量，当然前提是有足够的单元测试作为保护层，这也需要开发人员花时间为每个服务接口（或者高价值的部分）写单元测试！
如果构建任务中有一个 Stage 失败了，那么此构建任务则认为失败，会给开发团队和 Leader 发送邮件告警：
此外，我们还使用了一个用于大屏显示构建状态的插件—Build Monitor，在我们工作区后方的电视屏上会显示各个构建任务的实时状态，如果有任务失败了会变为红色：
并且，Build Monitor 还会将推进不可靠代码的提交者名字（git 账号名字）显示在屏幕中的构建任务里边，方便大家查看谁的锅：
三、ASP.NET Core CD 流程部分
经过 CI 部分，就可以初步认为提交的代码已经经过了初步的验证，这时会进入部署部分的构建任务，在我的流程里会有开发联调环境的部署及接口自动化环境的部署。当然，除了 API 的部署也有 Web 的部署，我们可以将其写到一个统一的 Pipeline 中也可以分开两个 Pipeline 来写。
下图是我的一个 API 的部署构建任务，其中会经历中台微服务的部署及 BFF 服务的部署，当然也可以部署至多个服务器：
这里说一下，由于我目前并没有采用任何的容器编排工具，所以这里的发布就只是单纯的将 release 文件覆盖之后然后将 docker 暂停和重启。这样做的缺点是没有充分利用镜像的优点，无法实现版本的有效管理（比如回退）。
四、RobotFramework AT 流程部分
对于一个产品来说，质量很重要，而保证质量的辅助手段就是充分的回归测试。自动化接口测试使得回归测试成为可以频繁触发，也就能及时发现提交的代码对已有接口功能的影响。我们的 AT 是根据重要的业务场景来写的，而且我们也觉得 AT 应该写在那些主要业务流程的接口上面，才能显示出它的价值，而且 AT 的编写也是不小的工作量。
我们使用的是 RobotFramework，开发语言是 Python。在开发人员提交代码并发布到开发联调环境时，便会自动触发 AT 环境的部署，部署无误后就会触发 AT 任务的执行，AT 执行无误后才会自动 Merge dev 分支的代码至稳定的测试分支，之后测试再选择是否发布最新的更改至测试环境进行验证 bug fix。
下图是基于 RF 的 AT 构建任务的执行结果：
下图是该任务的具体的输出信息，我们可以看到每个用例的执行情况：
由于我目前对这块了解不多，后续有机会了解多点后可以介绍一点我们在 AT 方面的实践和规范。
五、小结
本文介绍了我目前团队所在使用的持续集成全流程及一些重要插件的使用，虽然还很不完善，但初步解决了我所在团队在集成和发布上的一些痛点。随着后续对 K8S 的学习的深入，我会逐步引入 K8S 进行微服务的容器编排以及持续集成的 K8S 化改造，希望到时再进行分享。
