# Drone 还是 Jenkins?

在实践企业效能的提升时,自动化运维必不可少,在这其中 CI 和 CD 是非常重要的一部分,这次是我们平台最终选用了 Drone 来进行自动化,放弃了原有的 Jenkins,以及在搭建 Drone 的时候遇到的一些问题与解决方案。

# Drone 和 Jenkins 是什么?

一直以来,我们使用的都是 Jenkins 来做 CI,并且 Jenkins 也是行业标准的 CI 工具,并且插件很多,功能十分完善,几乎能够完成所有的 CI/CD 任务,但对于我们这种几十人到百人的团队来说,显得过于重量级。

随着大量的使用也带来了一些问题:

  • Jenkins 太重了,前面说过 Jenkins 能够帮助我们完成几乎所有的构建部署任务,但是它非常的重,修改起来有些麻烦。
  • UI 不好看,这是原来吐槽过最多的地方,它的 UI 简直是太简陋了。
  • 权限控制非常麻烦,也不能说这不好,Jenkins 对权限非常的精确,能够精确到每个人的权限,但是这就需要花非常多的时间去配置,时间一长权限混乱就非常不好处理。
  • 对容器化支持不是很好,但是后面出现的 pipeline 改善了这一点,但是还是感觉不好用

那 Drone 是什么呢?Drone 是一个 CI 的开源工具,说白了它其实是一个原生 Docker,所有的操作都在容器内进行,可以很好的贴合 K8s。Drone 的用户权限都是和源码库挂钩的,所以它本身是不具有这些东西的,整个工具非常的轻量级。

由于 Drone 需要和源码库连接,所以 Drone 是不能处理多个源的,而 Jenkins 可以做到多源的 repo 处理。

在插件方面来说,Jenkins 的插件非常的多,Drone 的生态相对来说就很小,但是基本所有需要的插件都能够在 Drone 中找到,同时,Drone 构建 Docker 镜像会非常简单,同时,Drone 本来就运行在 Docker 里,就少了很多的配置问题。

所以,如果您想要一个简单且能快速启动和运行的原生容器 CI 解决方案,Drone 非常值得一试,同时,Drone 已经能够满足我们团队对于 CI/CD 的需求,但是 Jenkins 也是 CI 界的霸主,那到底要使用哪一种解决方案,就见仁见智了。

# 遇到的问题

因为 Drone 只是做构建工具,我们希望项目的构建能够通过另一个平台进行触发,同时,能够自定义构建脚本。

# Drone 如何针对对应分支版本进行构建

这其实不算一个非常大的问题,但是,由于官方文档的更新不及时,造成了在 v1.2 更新的 API 没有在文档中体现,我们在查找了多方资料后,进到项目的 Changelog 里发现,Drone 已经支持了通过 API 去调用构建任务了。

我们可以通过 API 让 Drone 来完成构建的动作。

# 如何让 Drone 支持支持外部动态配置文件

这是遇到的最大的一个问题,根本原因是 Drone 只支持单仓库、单配置文件 (.drone.yml),且不能动态修改,所以,我们的需求是要做到这一个分支有多个构建任务,同时要可以自动构建,手动部署,并且构建脚本还要不一样。如果只是单文件配置就不能满足我们的需求。

为了解决这个问题,我们在 Drone 的官方论坛以及 Issue 中进行了查找,最后找到的解决方案是使用 DRONE_YAML_ENDPOINT 环境变量给 Drone 指定一个获取配置文件的服务地址,这个地址就是我们的效能平台,当每一个构建任务开始执行,就会给 DRONE_YAML_ENDPOINT 发送一个 post 请求获取配置文件,这时候我们就能够根据 body 里的数据进行配置文件的生成,然后返回给 Drone。