CI/CD现代史,从Jenkins到GitHub Actions

作者 | 吴晶晶

讲师 | 苗兆丰

编辑 | 张之栋、王文婧

CI/CD 是一种通过在应用开发阶段引入自动化来频繁交付应用的方法。CI/CD 的核心概念是持续集成、持续测试、持续交付和持续部署。作为一个面向开发、测试和运营团队的解决方案,CI/CD 主要针对在集成新代码时所引发的问题。CI/CD 的出现改变了开发人员和测试人员发布软件的方式。

腾讯前端开发工程师、腾讯内部 CI 工具 Orange-ci 的负责人苗兆丰( maplemiao ),将在 11 月 16 日举行的 Tweb Conf 大会中分享《CI/CD 现代史,从 Jenkins 到 GitHub Actions 》,欢迎关注。

Q1:为什么要使用自动化 CI/CD 工具?

苗兆丰:当然是让我们有更多的时间去专注于核心的事情,能够帮助我们把那些频繁、爱出错、重复的步骤自动化完成。不仅能够提高效率,而且能够让我们更容易把握远程代码仓库的代码质量。对于开源项目来说,这更是尤为重要的一环,可以帮助 Contributors 减少很多贡献代码或者文档的成本。总之,CI/CD 可真算是开发者的好朋友,如果你希望有更多时间做有意义的事情,请一定要尝试使用 CI/CD 工具。

Q2:在选择 CI/CD 工具时需要考虑什么因素?有哪些 CI/CD 工具是比较推荐的?

苗兆丰:首先是看项目所处的平台和自身的敏感程度。如果是 GitHub 上的开源项目,那自然不用多说,老牌的 Travis-ci、Circle-ci 和最新推出的 GitHub Actions 都值得使用。当然我个人更看好 GitHub Actions。如果是私有部署的代码托管平台,那么可能会优先考虑对私有化部署更友好的工具,比如 Jenkins X。

其次是看需要支持哪些环境的构建,一般来说,只是 Linux 平台构建的话,我推荐可以试试 Drone.io,是完全基于云原生的 CI 平台,科技感十足。如果是需要 Windows、Mac、Linux 三平台同时支持的话,那么我推荐还是优先考虑老牌的工具。

Q3:是否能简单介绍下目前的 CI/CD 行业生态?

苗兆丰:近十年来,CI 市场的波动并没有十分剧烈。私有化部署市场,Jenkins 一骑绝尘;公有云服务市场,Travis-ci 和 Circle-ci 各占半壁江山。但是站在 2019 年的视角往回来看,除了 GitHub Actions 最近引发了深水炸弹之外,在云原生概念 2015 年出来之后,确实给行业带来了新的变化。Drone.io 和 Jenkins X 便是 CI 与云原生化学反应的产物,至于前景如何,我们可以拭目以待。

Q4:在开发公司内部 CI 工具时你有什么特别体会?

苗兆丰:CI 本身的技术其实并不复杂,最复杂、关键的地方在于插件生态。Jenkins 从 2011 年就在私有化部署市场独领风骚,至今没有人能撼动。虽然它的界面丑的一样独领风骚,但就是没有另外一个产品能替代。原因就是它数年来积累的无数插件,甚至在 8 年以后,Jenkins 自家推出的 Jenkins X 都依然不敢在插件上大动手脚。所以插件是 CI 最重要的组成部分。未来假如有一款 CI 能挤掉前辈们,那一定是因为插件方面有革命性的优势。所以 GitHub Actions 选择拥抱 JS 社区,应该是一个无比重要的决定。

Q5:你认为未来 CI/CD 工具会有哪些可以改进的地方?

苗兆丰:如上文所说,插件非常重要,所以未来的 CI/CD 工具,首先插件有更方便的共享和开发机制。其次就是更好的拥抱云原生,更易于通过云原生的方式部署。

Q6:GitHub Actions 的诞生意味着什么?

苗兆丰:为什么是 GitHub Actions —— 微软的野心。

我们把视角拉远,其实可以清楚地看到,微软在花费很大的力气在云市场布局。从代码编辑器(VS Code && VS Code Remote),到代码托管平台(GitHub),刚刚进入 Beta 版本的包仓库,以及云平台 Azure ,微软都已经有了自家的重量级产品,但是仍然缺少一个核心的角色,就是 CI/CD,将整个流程串联起来。于是 GitHub Actions 便应运而生。

Q7:Docker Action 和 JavaScript Action 在实现上有何不同点?

苗兆丰:对于 GitHub Actions 诞生之初存在着一个的艰难抉择 —— Docker 还是 JS。在 GitHub Universe 2018,GitHub Actions 便已经开始了第一版内测,当时的 GitHub Actions 是全面拥抱 Docker 的:“An Action is a Docker container that runs as part of a Workflow.” 但是在 2019 年的公测版本上,我们却看到新增了一种方式。在 Docker Action 之上,增加了 JavaScript Action。我推测还是因为 Docker 的平台局限性,所以 GitHub 在不放弃这个 Docker 未来趋势的情况下,还是积极地拥抱了 JS 社区,毕竟世人皆知 JS 社区的强大活力。

把 JavaScript Action 和 Docker Action 做下对比:

JavaScript Action —— 真的很简单,首先来看一个常见的 GitHub Actions Workflow 长什么样:

steps 是一个数组,数组中的每一项,都是一个 Action。其中 uses: actions/setup-node@v1 将会转化为一个 GitHub Repo 地址:https://github.com/actions/setup-node/releases/tag/v1。

表示该步骤需要从该 Repo 中获取执行逻辑,我们看看这个仓库里面是什么内容:

除了 action.yml 文件之外,就是一个普通的 Node 项目,这个 action.yml 便是 Action 的描述文件,其中包含了名称、描述、输入输出,以及一个特殊关键字:runs。runs 描述了这个 Repo 代表的 Action 将会在 Node12 环境执行,入口文件是 lib/setup-node。

Docker Action 解析:

相比 JS Action 只有几个简单的地方做更改,甚至都不需要额外做解释:

表示直接从 Docker Hub 中拉取镜像执行,而非去一个 GitHub Repo 中拉取执行。当然,你想从 Repo 中拉取也是支持的:

Q8:GitHub Actions 有哪些关键特性?

苗兆丰:GitHub Actions 的特性可以用下图总结:

从 CI 行业来看,GitHub Actions 带来了下面一些新的想法:

GitHub Repo as Plugin,更广泛的去中心化。

Dockerfile 可以先构建再作为插件。

拥抱 JS 社区!

当然,作为刚诞生不久的产品,还有一些点需要解决,比如说为什么把 node_modules 上传到代码仓库呢?

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20191101A0KXC900?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券