你好,我是石雪峰。今天是期末总结,我们来聊一聊,在云时代,如何选择一款合适的流水线工具。

在过去的几年里,我一直专注于软件持续交付的工程实践领域。我发现,越来越多的公司(无论规模大小)开始重视软件持续交付能力的建设了,基本上每家公司都有自己的流水线平台。

以前提到CI/CD工具,基本上就默认是Jenkins,也没什么其他太好的选项。但是最近两年,随着云容器技术的快速发展,在CI/CD流水线领域,新工具和解决方案出现了爆发式的增长。比如不甘寂寞的GitLab CI、轻量级的容器化解决方案Drone。最近一段时间,GitHub的Actions也火了一把。可见,作为软件交付主路径上的核心工具,流水线是每一家企业都不愿意错过的领域。

对于行业发展来说,这当然是好事情。老牌工具Jenkins自己都开始反省:“在云容器时代,是不是过于保守?十几年的老架构是否已经难以支撑云时代的快速发展了?”于是他们就另辟蹊径,孵化出了Jenkins X项目。

但是,对于用户来说,选择工具时就很为难:“这些工具看起来大同小异,要解决的也是类似的问题,到底应该选择哪个呢?”

今天,我就来给你梳理一下流行的CI/CD工具,并给你提供一些选择建议。我挑选了5个工具,分为3组介绍,分别是Jenkins系的Jenkins和Jenkins X、版本控制系统系的GitLab CI和GitHub Actions,以及新兴的、正在快速普及的云原生解决方案Drone。我会从5个方面入手,对它们进行对比和介绍,包括工具的易用性、流水线设计、插件生态、扩展性配置以及适用场景。

Jenkins/Jenkins X

关于Jenkins,我想已经不需要做太多介绍了。在过去的15年里面,Jenkins一直都在为无数的软件开发者默默服务。从一组数字中,我们就能看出来它的影响力:官方能统计到的集群数有26万多个、插件将近1700个、执行的任务数超过3000万次,这还不包括大量公司自建、本地电脑运行的节点信息。另外,一年两次的Jenkins全球大会往往能够吸引上千人参与,这对于国外的技术大会来说,已经是超大规模的盛会了。

当然,Jenkins的优缺点也很明显。

我重点说说Jenkins X。很多人都不清楚Jenkins和Jenkins X是什么关系,这就好比刚开始我们很难说清楚Java和JavaScript的关系一样。实际上,JavaScript除了名字上带有“Java”字眼,蹭了个热度之外,本质上它们之间并没有什么关系。而对于Jenkins和Jenkins X来说,虽然并不能说二者一点关系没有,但其实它们面对的场景和要解决的问题是不同的。所以,并不能说Jenkins X就是下一代Jenkins,或者是Jenkins迟早会迁移到Jenkins X上面。

Jenkins X最开始的确是作为Jenkins的子项目存在的,但是发展到现在,它已经有了独立的品牌和Logo,并且和Jenkins一起作为CDF(持续交付基金会)的初始项目。Jenkins X想要解决的核心问题是Kubernetes上的原生CI/CD解决方案。所以,Jenkins X和Kubernetes是强绑定的关系,它致力于通过一系列的自动化工具和最佳实践,来降低云原生环境下的研发配置和使用CI/CD的成本,并尽可能地做成开箱即用的状态

而Jenkins更像一个百宝箱,你可以通过插件扩展来解决各种各样的问题,并没有一定之规。

我给你举个例子,来形象地对比一下Jenkins和Jenkins X这两个项目。

Jenkins就好比你在开车,你知道目的地,但是走哪条路,开多快,中间要不要休息一下,什么时候加油,这些都是你自己来决定的。当然,灵活性带来的就是多变性,你并不知道是不是下一秒就封路了或者是汽车突然坏了。

而Jenkins X更像是一辆高速列车,你只要上对了车,列车会把你安全、快速地送往目的地,而你并不需要关心这个车是怎么设计的,时速应该是多少,甚至你在哪里能够下车,它都规定好了。

Jenkins X项目中内建了大量的开源工具和解决方案,可以说是开源工具的理想国和试验田,核心目的就是为了简单、快速、开箱即用。比如对Tekton的集成,就被视为对Jenkins自身的颠覆,因为这彻底改变了Jenkins流水线调度机制。因为在Jenkins X看来,Jenkins只不过是Jenkins X中的一个应用,是一个黑盒子,编排通过Tekton来实现,换句话说,即便你想用其他应用来取代Jenkins,也不是不可能的。

值得注意的是,Jenkins X中有很多约束,比如你必须使用GitOps的方案来完成应用的晋级和部署,没有其他的选择。如果你没有使用Helm管理应用,也不想使用GitOps,那就现阶段来说,Jenkins X对你就不是一个可选项

我们来总结一下Jenkins X项目:

GitLab CI/GitHub Actions

除了Jenkins,国内使用比较多的应该当属GitLab CI了。前些年也有过社区的讨论,到底应该使用GitLab CI,还是Jenkins?很显然,这样的讨论并不能达成共识,毕竟“萝卜白菜,各有所爱”。而GitHub Actions的推出,也是看中了流水线编排领域的“蛋糕”。曾经,GitHub和TravisCI是珠联璧合,可以说是“开源双碧”。GitHub也一再强调,自己只想把代码托管服务做到极致,其他领域都交给合作伙伴完成。但是今天的Package功能和Actions功能都体现出了GitHub自建生态的野心。

其实,这两个产品有很多相似之处,因为它们都是依托于一个成熟的代码托管平台衍生出来的原生流水线功能。

对于软件开发而言,最重要的无疑就是源代码。之前,我有个同事就说过,只要掌握了源代码,你就可以为所欲为了。比如,基于代码拓展代码评审工具、内建各类静态动态代码检查功能、增加包管理和依赖管理工具等,这些是代码编译之前和编译之后的必备功能。增加内建的持续集成功能,也有助于在代码评审的时候做到机器辅助。

当这些功能都集成到代码托管系统中时,你就会发现,它不再是一个简单的版本控制系统了,而是一整套DevOps平台。它们的设计理念是,一个平台解决所有DevOps的工具问题。这一点在GitLab的路线图规划中,也体现得淋漓尽致,GitLab对主流工具都进行了对比,并提供了一个工具的全景图。可以说在行业对标方面,GitLab是做到极致了。你可以参考一下下面这张全景图和他们自己写的对比文章

图片来源:https://about.gitlab.com/devops-tools/

回到流水线方面,GitLab CI和GitHub Actions都和版本控制系统进行了深度集成。我们还是从五个方面来整体看一下。

1.工具的易用性

2.流水线设计

3.插件生态

4.扩展性配置

它们都支持多种环境类型。GitLab很早就提供了对容器和Kubernetes的支持,GitHub在这方面自然也不会落后,官方提供了Linux、Windows和Mac环境的支持,你也可以自建节点并注册到GitHub中。不过必须强调一点,GitHub如果是非企业版本的话,是不支持私有化部署的,这也就意味着,如果你想把企业内部的资源注册到GitHub上,那么就意味着这些资源必须对外可见。

5.适用场景

由于国内GitLab自建服务的普及,如果你对CI的功能要求没有那么高,那么GitLab CI就足够了。但是,在功能广度方面,由于缺少庞大的插件生态,很多功能还是更多地依赖于你自己实现,所以,如果软件交付流程非常复杂,依赖于多种环境,GitLab CI就不是那么适用了。

而GitHub在企业中的使用场景就更加有限了,一方面是成本问题,另一方面,SaaS化服务依赖于内部开放性。所以,如果是开源项目,或者创业项目不希望自己维护一套很重的研发基础设施,那么我建议你考虑使用GitHub的方案。

在最新发布的2019年Forrester的趋势报告中,GitLab和Jenkisn都入选了云原生CI工具的榜单,并且处于行业领先地位,你可以看一下报告的图片。虽然图中没有写明Jenkins,但是其背后的CloudBees公司,以及目前在云原生项目Jenkins X中有深度合作的Google公司都处于领先地位,由此可以看出,各大公司都已经开始在云原生领域布局了。

Drone

这也是一个近来冉冉升起的CI工具领域的新星。在咱们专栏的留言中,有很多同学提到过这个工具,可见,好工具是会自己说话的

Drone主打的就是云原生CI,整体设计非常轻量级,即便没有什么经验,一两天也能快速上手搭建。在我看来,Jenkins X虽然也是主打云原生,但由于引入了大量组件和流程约束,整体还是略显笨重一些。相反,Drone的实现非常优雅,无论是流水线的语法,还是环境的扩展性方面,都让人不由得赞叹。

作为一个开源软件,Drone使用Go语言实现。在我看来,Go就是为云原生而存在的,无论是Docker、Kubernetes,还是我参与的Jenkins X项目,都是通过Go语言来实现的。所以,这个项目对于内部开发团队快速提升Go语言的DevOps平台建设能力,也是一个很好的参考学习案例。

对于Drone平台,我目前也在学习和探索阶段,我从下面这几个方面谈谈我个人的看法。

1.工具的易用性

Drone的搭建非常简单,你可以采用自建服务的形式,也可以使用SaaS服务。UI风格设计体现了恰到好处的理念,整体非常清爽,同时也能跟其他工具(如GitHub)进行集成。

2.流水线设计

作为云原生的解决方案,流水线同样采用yaml形式、具备描述式表达和流水线即代码的功能。虽然没有过于复杂的语法,但是Drone的流水线语法风格是我个人最喜欢的,它的结构非常清晰。

3.插件生态

Drone也提供了插件机制,而且官方还提供了对主流版本控制系统和云服务商的集成支持。虽然数量远远比不上Jenkins生态,但是你能想到的基本都有了。比如常见的Artifactory、SonarQube、Ansible等工具,甚至还包含了对微信、钉钉这类国内流行的通讯软件的集成。由于它的开放特性,未来它也会提供更多的插件。

4.扩展性配置

对于Drone来说,最大的特征就是容器优先。上面提到的这些工具虽然都支持容器,但是并没有把容器作为默认支持的第一选项。而在Drone中,容器则是标配,这也是典型的云原生CI工具的特征:一切都在容器中运行。也正因为如此,非容器化开发部署的项目如果采用Drone就不太合适了。另外,除了容器方式之外,Drone也支持本地执行,这为一些特殊的场景提供了可能性(比如绑定设备的自动化测试等)。

5.适用场景

我认为,Drone在云原生CI/CD方面的设计代表了未来的趋势。对于基于容器开发交付的产品来说,如果你在寻找一个对应的云原生解决方案,那么我推荐你用Drone。它也比较适合于中小型团队、初创公司想要快速受益于CI/CD,又不想投入太多精力的场景。同时,作为一款Go语言开发的开源软件,随着业务扩展,你大可以自建插件,满足差异化的需求。

总结

最后,为了方便你理解和进行对比学习,我把这五个云原生流水线工具的特征汇总了图片里。

到此为止,这几款主流的流水线工具,我就介绍完了。在文章的最后,我还想再补充两点:

  1. 工具并非决定性的因素,不要轻易陷入“工具决定论”的思想之中,就好比真正的编程高手可能都不需要IDE,选择好的工具,并不代表就有好的结果。
  2. 工具是“存在即合理”的,它们都有各自擅长的领域,没有绝对意义上的最好,只有最适合的场景。另外,即便是同一个工具,在不同的人手中发挥的作用也不一样,选择自己最熟悉的工具,一般都不会有错。比如你要问我选择什么工具的话,我肯定推荐Jenkins。但这并不是因为Jenkins完美无缺,而仅仅是因为我用得顺手而已。

思考题

对于Drone这款工具在生产环境的应用,你有哪些实际的经验,又踩过哪些“坑”呢?

欢迎在留言区写下你的思考和答案,我们一起讨论,共同学习进步。如果你觉得这篇文章对你有所帮助,也欢迎你把文章分享给你的朋友。

评论