在云原生时代，持续集成应该是什么样子？|腾讯技术开放日第二期
发表时间：2023-09-09 13:00:47
文章来源：炫佑科技
浏览次数：147
菏泽炫佑科技
在云原生时代，持续集成应该是什么样子？|腾讯技术开放日第二期
持续集成（CI）是指开发人员定期将代码变更合并到中央存储库中，然后系统自动运行构建和测试操作，通过频繁的集成来控制代码质量。
经过几十年的发展，持续集成已经成为软件开发的标准配置，并为开发者所熟知。 如今，软件公司不使用持续集成是不可想象的。
在持续集成工具链中，起步早，积累也多。 以其良好的生态和丰富的插件而被广泛使用。
但进入云原生时代后，应用部署和基础设施都发生了重大变化，并没有跟上。 反而暴露了一些问题，比如管道编排引擎不够稳定、并发性能差、开发插件麻烦等等。
那么云原生时代的持续集成应该是什么样子呢？
上周末我参加了第二期腾讯科技开放日。 本期的主题是云原生全栈开发与实践。 其中一场会议恰好是关于云原生时代的持续集成。 谈到了腾讯云CI 3.0。 读完之后，我觉得To：这可能是未来的发展方向，今天就跟大家分享一下。
作为代码
云原生提倡“基础设施即代码（as Code）”，即基础设施通过代码来定义，并由版本管理系统进行管理，这对应于持续集成，即作为Code。
众所周知，持续集成是一系列任务的编排，例如：
图解背后是配置文件（以此为例）：
pipeline {
agent any
stages {
stage('检出') {
steps {
checkout([$class: 'GitSCM',
branches: [[name: GIT_BUILD_REF]],
userRemoteConfigs: [[
url: GIT_REPO_URL,
credentialsId: CREDENTIALS_ID
]]])
}
}
stage('单元测试') {
post {
always {
junit 'build/test-results/**/*.xml'
}
}
steps {
sh './gradlew test'
}
}
......
这种方法有两个缺点：
1. 往往是命令式的，需要对操作的每一步进行精确的通知。 编写和维护都不方便。
2. 受管理，不方便配置复用。
腾讯云 CI 3.0 通过简单的 YAML 文件解决了这两个问题。
这个例子的意思一目了然：当分支有推送时，就会触发一次构建。 构建是在容器:8中进行的，只输出一个文本：hello world。
就可读性/可维护性而言，纯文本声明性配置文件比命令式代码干净得多。
而且这种文件可以保存在代码仓库中，不仅方便版本管理，也方便不同项目、团队之间的复用。
基于容器的CI设计
上面的例子中已经提到了容器。 事实上，腾讯云CI 3.0完全是基于容器设计的。
这是什么意思？ 让我们通过一个简单的例子来理解。
假设您的 CI 有两项任务，一项用于编译，一项用于测试。 执行过程中，代码会从代码仓库下载到某个目录，然后将该目录挂载到容器中进行编译，然后挂载。 转到另一个容器进行测试。
与虚拟机（VM）相比，镜像启动速度非常快，并且易于使用，并且所有对环境的依赖都在YAML文件中声明，并且可以被仓库遵循。
master:
push:
stages:
- name : compile
image : docker-image-1
script: xxxx # 做编译的脚本
- name : test
image : docker-image-2
script : xxxx # 做测试的脚本
事实上，在CI 3.0中，任务编排分为三个级别：Stage、Job。
一个阶段可以有多个阶段，一个阶段可以有多个作业。
容器可以在三个级别上使用：
可以看到，系统默认会使用顶层声明的镜像。 如果在下层声明了新图像，它将覆盖上层。
一个系统要繁荣并具有长久的生命力，生态系统是必不可少的，并且能够被广泛接受。 大量的插件发挥着重要作用。
然而插件开发对于程序员来说并不是很友好。 他们必须掌握Java语言，熟悉插件约定，找到相关的扩展类，并实现自己想要的业务逻辑。
然而，基于基于容器的CI设计，开发插件突然变得简单了，因为插件本质上就是容器，你可以在容器中使用任何语言，不受任何限制。 CI 3.0还支持直接使用Hub上现有的容器插件。 目前支持的生态系统包括Drone等。
更神奇的是，CI 3.0还支持在管道中直接执行命令，甚至可以直接在管道中使用——编排服务！
例如，如果运行自动化测试时需要依赖MySQL、Redis等服务，可以直接用命令启动它们在云原生时代，持续集成应该是什么样子？|腾讯技术开放日第二期，然后在后续作业中使用它们，非常方便。
高性能 CI
对CI背后的工作机制有深入了解的同学可能会有这样的体会。 CI每次运行时，都会在磁盘上生成大量的项目文件：源代码、依赖库（如：）、编译生成的中间体等。
这对于某些情况是非常不利的。 例如，一个项目有两个分支。 对于两个管道来说，实际上运行后，生成的文件很多都是相同的，这是一个巨大的浪费。
相同的文件可以重复使用吗？ 喜欢缓存它们吗？
这很困难，因为不同的管道可能会读写同一个文件，从而导致冲突。
这成为并发读写操作的经典问题，解决方案无非是：
1. 锁定缓存
执行一次管道访问后，释放锁，允许另一次管道访问。 并行管道变成串行管道。
2. 复制一个缓存到每个管道
随着缓存数据变得越来越大，复制本身就成为一个巨大的负担。
3、保留多个缓存，超过并发数时进行排队。
相当于设立了一个池子，先满足一些流水线的需求，而其他流水线则排队。 然而，随着单个管道长度的增加，排队的管道将会越来越多。
CI 3.0的解决方案是使用Copy-on-Write来复制缓存，瞬间即可完成。
这里简单介绍一下。 它是一个堆栈式文件系统，不直接参与磁盘结构的分区。 相反，它依赖于并构建在其他文件系统（例如 ext4、xfs）之上。 它的目标是将原来的底层文件系统中不同的目录进行“合并”，然后呈现给用户。
如下图： 中的文件由 和 合并而来。
“底层目录”中的FileA和FileB可以修改，“底层目录”中的FileC和FileD是只读的。
如果你想修改这些文件，你就复制一份并在这里修改。 当然，修改后的文件会“覆盖”底层目录中的文件。
你可能立刻想到，如果把这个特性应用到持续集成中，不就解决了缓存读写冲突的问题了吗？
每个管道使用一个软件开发，对应于下面的一个。 底层是只读的，存储缓存数据。
如果某个管道想要修改缓存数据，请在 . 只有该管道可见，其他管道仍然可以看到底层只读缓存。
腾讯云的CI 3.0利用这种即时复制技术，大大提高了多个管道并发运行的效率。
目前，越来越多的公司和团队使用一种方法来管理代码，即多个项目的代码存储在同一个存储库中。 可以想象，这样的代码仓库可以高达几十G，甚至上百G。
对于这样的代码库，如果你在管道中做一个git克隆，将代码从仓库下载到工作目录，那需要花费的时间可想而知！
CI 3.0利用技术，针对这种大型仓库场景进行了优化：
管道完成**次 git 克隆后，代码已下载到本地。 后续的 只要找到这个仓库的代码，就可以通过复制一份作为缓存来创建自己的，然后根据缓存执行 git fetch 操作。 这样管道就可以快速启动。
这样，代码准备时间就可以降低到秒级，大大提高了流水线的性能。
CI助力远程开发
疫情期间，如果出现紧急情况，工作电脑不在身边，程序员就惨了，基本无法工作。
因为现在的系统非常复杂，一个应用依赖了很多缓存、搜索、数据库等服务，想要重新构建起来很困难，代码量也越来越大。 即使在本地下载也非常耗时。 时间的事。
我们很自然地想到：代码库存储在服务器端。 我们能否在服务器端快速搭建一个开发环境，让程序员可以使用浏览器或者连接浏览器进行远程开发？
CI 3.0已经是基于容器设计的，可以很容易地创建容器，可以用来构建环境。
这是一个简单的例子：
每当创建分支时，都可以自动触发 CI 管道，建立新的开发环境。 程序员无论身在何处，只需打开计算机浏览器即可开始编程。
总结
如今已经进入云原生时代，持续集成也需要拥抱变化，与时俱进。
腾讯云CI 3.0基于容器设计，以Code方式实现，方便程序员开发插件。 它通过利用极大地提高了CI的性能，创新性地帮助程序员创建远程开发环境。 这些功能帮助公司提高 CI 效率，更好更快地交付有价值的软件。 强烈建议大家尝试一下。
本文只是冰山一角。 在上周末举办的Techo Day腾讯技术开放日活动上，对CI 3.0的技术原理进行了更深入的剖析。 相关资料和课件整理整理成《腾讯云原生工具指南》。 除了CI之外，还涵盖了Crane、AUTO分布式云操作系统等热门产品，以及开发专家推荐的帮助解放生产力的工具列表。 有太多值得一看的东西，不要错过！
