3.3　持续集成

持续集成（Continuous Integration，CI）是指持续地、自动地把多个研发提交的代码通过的一系列流程（构建、测试、打包等）处理到对应的分支中。持续集成通常以流水线（Pipeline或Workflow）的形式存在，可以确保代码（以及相应的配置文件等）在确定的环境中，以确定的方式编译、构建，避免由于环境差异导致的问题。除此之外，实际应用中还会产生固定格式的制品文件，极大地方便了后续的交付流程中其他成员的使用。

持续集成领域有大量优秀的商业、开源解决方案，鉴于开源方案（项目），更方便从互联网上检索资料、获取帮助，以下重点介绍开源的持续集成方案。

1.Jenkins

Jenkins是一个完全由开源社区驱动的开源项目，是持续交付基金会（Continuous Delivery Foundation，CDF）旗下的四个初始项目之一。Jenkins用Java语言开发，有着丰富的插件生态（任何人都可以按照社区流程申请，把自己研发的插件托管到社区，目前插件总数约为1800）和非常庞大的用户群体。Jenkins提供了多种官方的交流途径，包括邮件列表、Gitter、论坛、GitHub项目列表、Jenkins中文社区维护的微信群等。Jenkins社区有两个版本发布的频率：每周版（weekly）和长期支持版（Long-Term Support，LTS）。长期支持版基本保持每个季度发布一次。Jenkins可以通过直接运行jenkins.war的方式启动，或者在类似Tomcat的应用容器中启动，也能以容器或在Kubernetes中运行。

Jenkins的主要特色包括：流水线即代码（Pipeline as Code，PasC）、配置即代码（Configuration as Code，CasC）。

所谓Pipeline（流水线），是指将持续集成流程用Groovy脚本的形式写入Jenkinsfile，让Jenkins解析并执行。Jenkinsfile可以在Jenkins的UI界面上，也可以写入代码仓库（如Git或SVN）。Pipeline有两种编写风格，分别为脚本式、声明式。脚本式的写法与普通的Groovy脚本类似，而声明式Pipeline中默认无法定义变量或者添加逻辑代码，如果必须在声明式Pipeline中添加逻辑代码，就必须放到脚本代码块中。所谓配置即代码，是指可以将Jenkins的系统配置以YAML的格式存储，用户需要修改配置时，不需登录UI界面，直接修改YAML文件即可；CasC使得Jenkins配置标准化，便于复用和变更追踪。

下面是一个简单的Jenkinsfile示例：

Jenkins也有一些劣势，尤其在云原生的大潮流下体现比较明显：

❖所有的配置、数据都是直接从文件系统中读取，随着负载增加，性能会有较大的下降。

❖有发生单点故障的可能性，目前没有高可用的方案。

❖社区的各种插件在质量上良莠不齐，也没有统一的插件开发规范，部分插件可能导致兼容性问题。

❖没有标准Restful风格的API，作为第三方，组建集成依赖时缺乏统一的对接标准。

❖内存和CPU消耗较多。

2.Tekton

Tekton是一个云原生的、用于构建CI/CD系统的解决方案，提供了Pipeline。同样，Tekton也是持续交付基金会（CDF）旗下的四个初始项目之一，最初由谷歌公司开源。

Tekton基于Kubernetes CRD（Custom Resource Definition，用户资源定义）抽象了一些通用的概念，如Step、Task和Pipeline等，提供了基于事件机制的Trigger（触发器）、命令行（Command Line Interface）工具tkn和简单的UI界面Dashboard。

Tekton充分利用了云原生和Kubernetes架构的优势，核心逻辑以Controller的方式运行在Kubernetes中，无状态的服务容易实现高可用性。根据标准的CRD，Tekton可以作为第三方组件进行集成，但由于Tekton对资源做了高度抽象（非常通用），如果直接使用，会感觉非常烦琐、复杂，难以做到开箱即用。而且，Tekton官方提供的UI界面功能简单，难以直接满足企业的使用场景。

3.Jenkins X

Jenkins X是一个云原生的、集成了许多DevOps工具链的常用组件，用于自动化整个软件交付流程，也是持续交付基金会（CDF）旗下的四个初始项目之一，最初由Cloudbees公司开源。值得一提的是，Jenkins X与Jenkins在版本迭代、演进上并没有直接关系，Jenkins只是被集成的组件之一。

Jenkins X基于GitOps提供了自动化的CI/CD、环境管理、ChatOps等强大的功能，但由于缺乏UI界面，学习、上手难度大，国内的学习资料较少、采用率不高。

4.GitLab CI

作为GitLab整体的一部分，GitLab CI不需单独安装。用户只需把CI/CD的配置写到代码仓库根目录的文件.gitlab-ci.yml中，即可实现与GitLab的其他功能（如代码仓库、制品仓库、凭据管理等），实现无缝对接。对于计划采用GitLab整体方案的团队而言，GitLab CI的优势很明显，不需维护额外的第三方组件。但GitLab本身也是一个复杂、庞大的项目。

5.GitHub Actions

GitHub Actions是由GitHub提供的，虽然不开源，但可以免费使用（有使用时长限制）。与Gitlab CI类似，用户只需要把CI/CD配置以YAML格式写到目录（.github/workflows）中即可运行。而GitHub Actions的YAML格式非常清晰、简单，通过GitHub官方给出的示例、文档以及GitHub上海量开源项目的使用案例，用户的学习成本并不高。但其明显的缺点是，不是开源的，所以难以脱离GitHub使用。

下面是一个简单的GitHub Actions示例： JFV+e8MCObP6lhxBrD9Gusj6PJvnO9Vn0jsQDXTaoMI8WH2XrNbYTHE3G65GwZhr