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

Posted 2021-04-07 前端之巅

作者 | 吴晶晶

讲师 | 苗兆丰

编辑 | 张之栋、王文婧   

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 长什么样：

           

表示该步骤需要从该 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 上传到代码仓库呢？