关于持续集成:新一代-CI-即将到来

本文转载 CodeSheep。
作者受邀加入 Techo Day 腾讯技术开放日线上流动，播种颇丰，有感而发。

上期 Techo Day 腾讯技术开放日流动讲的是「轻量级工具」，这一期次要讲的是「云原生」。

在所有课题里，集体比较关心的是 CI 设计 这个课题——CODING CI 3.0，比传统 CI 好在哪里？

CI 全称 Continuous Integration，名为「继续集成」，传统的 CI 含意指的是代码仓库只有有代码变更（或者说有人想推代码入库），就会主动执行事后设计好的查看、防护流程，运行一系列构建、测试、部署等流程，并最终告知每一步的运行后果，确保人提交上来的代码没有问题后，才有机会将新代码合并到骨干分支，而骨干分支无论何时都肯定是正确可运行的高质量版本，能够随时交付客户应用。

继续集成的词面意思其实某一水平上也道出了该做法思维的精华：即小步快走，继续地去做代码集成。

不得不说继续集成在古代软件研发流程中，表演了非常重要的角色。

平时的工程中，总有一部分工作是绝对机械化，易出错的（例如打包、部署），咱们能够把这部分工作交给机器来做。让继续集成构建打算进行自动化的单元测试、代码查看、编译构建、契约测试，甚至主动部署，可能大大降低开发人员的工作累赘，缩小许多不必要的重复劳动，继续晋升代码品质和开发效率。

聊到 CI 零碎，那不得不提的就是 Jenkins 了，它是一个应用宽泛的继续集成工具。

然而不少团队或我的项目应用 Jenkins 零碎的眼光还局限于在 Jenkins 上建各种各样的 Job 来实现 CI 工作，所以仍然存在不少痛点，典型的比方：

配置繁琐且不灵便，尤其是对于新拉分支的 CI 部署比拟麻烦，配置的可扩展性和可复用性有待进步。
传统的 Jenkins Job 难以灵便高效地并行（包含 Job 间、节点间、工作间、甚至工作内等各个维度的并行），所以工作执行效率有待进步。
传统的 Jenkins Job 日益失控的趋势让咱们措手不及，Job 太多，CI 脚本太离散，保护老本切实太高了，而且很危险，一旦 Jenkins Server 挂了，所有都 Game Over 了，须要从新搭建了。
现在很多的业务上云了当前，如何对云端代码疾速构建一个高效的 CI 零碎也成了一个必须要面对的问题。

CODING 继续集成是 CODING DevOps 的子产品，其全面兼容 Jenkins 的继续集成服务，反对 Java、Python、Node.js 等支流语言，并且反对 Docker 镜像构建，图形化编排，高配集群多打算并行构建全面提速您的构建工作。反对支流的 Git 代码仓库，包含 CODING 代码托管、GitHub、GitLab 等等。在构建依赖拉取方面，应用专用网络优化包含 Maven，NPM 等支流镜像源，保障拉取速度，进一步晋升构建速度。

而现在在这次的流动上，腾讯云又推出了 全新的 CODING CI 3.0。

CODING CI 3.0 是腾讯云面向云原生打造的全新 CI 平台，基于 OverlayFS 的高性能 CI 技术，为继续构建利用、灵便定制流水线提供高效、稳固的服务保障。

所以接下来就来聊一聊这次公布的 CODING CI 3.0 的一些个性和劣势。

YAML 格局的申明式配置文件置信大家都不生疏，各种企业级我的项目里用得比拟频繁。

而此次的 CODING CI 3.0 同样反对通过通过 YAML 配置文件的形式来申明并疾速拉起一条流水线，十分便捷，并且易于了解：

master:
  push:
    - docker:
        image: node:14
      stages:
        - name: 依赖装置
          script: npm install
        - name: 测试用例查看
          script: npm test

比方下面这个案例形容的流程如下：

申明了在 master 分支在收到 push 事件时（即有新的 Commit 推送到 master 分支）的时候；
会抉择以 node:14 Docker 镜像（opens new window）启动的容器作为构建环境；
顺次执行工作 npm install 和 npm test。

另外，因为该 YAML 配置文件和我的项目源代码一样都作为仓库文件，一起被托管和版本控制，所以齐全遵循 Pipeline as Code 的思维，这样后续不论是 CI 流程的合作以及版本追溯都十分易于进行，而且也更利于实现 CI 配置的复用。

这样一来，设计 CI 流程 = 设计申明式配置代码，所以也十分合乎程序设计的思维。

咱们都晓得云原生时代十分典型的一个代表技术就是容器了，同理云原生时代的 CI 设计也必须兼容和反对容器技术。

CODING CI 3.0 基于 Docker 技术生态，对构建环境、存储、插件进行形象，更彻底地反对 Pipeline as Code。

当然这里有多个层面的设计思维。

1. Docker image as env

用户能够通过在配置文件里间接指定应用所需的 Docker 镜像，甚至是 Dockerfile，就能够指定 CI 流程中所用到的一些根底构建环境。

通过 Docker 镜像来指定构建环境

通过 Dockerfile 来指定构建环境

2. Docker image as plugins

同时 CODING CI 3.0 也反对在配置文件中应用 Docker 作为流水线插件，反对应用任意语言编写插件，从而扩大更多的性能。

同时其也反对间接应用 Docker Hub 上已有的容器插件，目前反对的生态有：Drone Plugins 等。

3. Native docker support

第三个层面就是原生 Docker 服务的反对，包含间接执行各种 Docker 命令以及脚本。

具体来说，一是反对在流水线上间接执行 Docker 命令，另外也反对在流水线上间接应用 docker-compose 编排服务。

在上文中也提到，传统的 CI 流水线中一个很麻烦的问题就是工作的并行和效率，尤其是当代码仓库十分宏大的时候。

这时候在拉起多条 CI 流水线时不可避免地就会呈现速度慢和效率低的问题。

针对这个问题，在传统的 CI 实际中也有一些常见的解决方案，比方：

已有的计划	存在的问题
流水线加锁	并行变串行，须要排队执行
保留多份缓存，超出并发数时排队	随着单个流水线应用增多或时长减少，会须要一直进步并发数，来保障构建速度
呈现并发流水线时，先复制一份缓存	随着缓存数据变大，复制自身的耗时也会越来越大

而这次推出的 CODING CI 3.0 则是通过基于 OverlayFS 的高性能计划来解决这个问题。

其本质上是应用缓存，而后次要通过 OverlayFS 技术实现缓存的“霎时复制”。

这里艰深来了解就是，第一次执行没有缓存的时候，所有流程走完一遍，执行 git clone 命令，把整个仓库克隆下来；但后续的 CI 流水线，只有发现机器上有这个仓库的代码，就能够先通过 OverlayFS 技术复制一份缓存来用，而后在缓存的根底上进行 git fetch 操作，因而每条 CI 流水线都能很快启动。

这样一来，即便是上百 GB 容量的仓库，也都能够在秒级实现代码克隆。

如下图所示，当 clone 形式从 git worktree 切换到 OverlayFS 刹时复制计划后，带来的成果就是代码的筹备工夫大幅度缩短，从而提高效率。

咱们都晓得传统的本地开发模式有着很多缺点和有余，突出表现在以下几点：

仓库多，环境无奈互相隔离；
开发环境简单多样，每个人都须要重新配置；
切换办公机 / 近程办公后，重新配置环境麻烦；
克隆代码和构建速度慢；
本地机器性能无限，影响开发效率。

所以此次 CODING CI 3.0 带来的一项很重要的能力就是反对近程开发服务运行在 CI 上。

即推出了一套 基于 CODING CI 的近程开发计划，随时随地一键启动开发，无需繁琐的操作，就能够为开发人员打造出一套现成的环境，从而能够享受无比晦涩的编译构建以及开发测试体验。

而且不同的人拿到环境，只须要改一下配置，就又能够迅速拉起一套 CI 开发环境，所以十分不便高效。

而用户只须要通过浏览器或者相似 VS Code 这样的终端软件即可参加近程开发。

一旦有 Git 事件或者 Open API 触发了 CI 流水线，CODING CI 就能够主动创立工作区，并且启动近程开发服务。

另外此次 Techo Day 腾讯技术开放日流动所有的材料和课件都整合成了一份《腾讯云云原生工具指南》，外面详尽介绍了涵盖 CODING CI 3.0、遨驰分布式云操作系统在内的腾讯云热门产品技术原理，能够说十分实用了，感兴趣的小伙伴能够 扫描下方二维码 ，返回 材料专区 下载查看。

关于持续集成:新一代-CI-即将到来

前言

传统 CI 的问题和痛点

CI 的概念

传统 CI 问题和痛点

什么是 CODING CI 3.0

CODING CI 3.0 个性和设计

通过 YAML 文件申明流水线

基于容器技术的 CI 设计

基于 OverlayFS 的高性能计划

CI+ 近程开发

总结