GitHub Actions：真正的 DevOps CI

在 GitHub Actions 诞生之前，业界已经有不少持续集成（Continuous Integration，CI） ，比如 Circle CI，和 GitHub 深度打通，体验已经很好了。那么 GitHub Actions 有什么优势，是否值得大家学习和使用呢？

CI 对比

从下图可以看出，GitHub Actions 和 Circle CI 区别不大：

唯一的区别是：GitHub Actions 不支持网页图形界面。这恰恰是一个优点，实现了真正的 DevOps（开发干掉运维）。因为只要有网页界面，就会有运维问「如何配置权限，不准开发修改流水线，只能运维统一配置」……

Pipeline as Code

「Pipeline as Code」有几层境界：

1. 流水线可以放在代码库，也可以放在网页上，或者各放一部分，而且往往命令行工具（cli）不完善，导致运维使用网页权限霸占了流水线，比如 Jenkins 就是如此落后（毕竟是古董级 CI，历史包袱重）。

2. 代码库 + cli 可实现所有功能，无需打开网页，但提供了网页，导致运维可能使用网页权限霸占流水线，比如 circleci.com、travis-ci.com。

3. 流水线可以脱离业务代码，放在单独的代码库中，导致运维独立创建代码库，设置了保密权限，霸占了流水线。

4. 代码库 + cli 可实现所有功能，不提供网页。而且流水线代码必须和业务代码放在一个仓库中，也就意味着每个开发都可以学习和修改流水线。

GitHub Actions 位于第 4 层，传统运维会担心：开发不懂服务器，不懂持续集成，乱改怎么办？

答：

1. 云计算时代，点击网页就开通了服务器，谁不懂？不让开发接触服务器，如何成长为架构师？

2. 放在代码库里才是最安全不会被乱改的，「设置保护分支，开展 Code Review」是正规项目的基本要求。

一站式

原来 GitHub 只做「Git 和开放」，被微软收购以后做了 Actions，逐渐形成「一站式」，算是小优点吧：

1. 开发者不用登录第三方 CI，稍微方便一点点。不过其实 CircleCI 等第三方也是 GitHub OAuth 登录，而且上架了 GitHub 应用商店，与 GitHub Actions 的体验几乎一致；

2. 向新手普及「持续集成」概念：开发者提交代码到 GitHub，看见旁边有个 Actions 图标，点进去就学到了 CI，而以前开发者可能埋头写了很多年代码，也不知道 Circle CI 、Codecov。

结论

1. 如果老项目已经在用 Circle CI 了，那没必要迁移到 GitHub Actions。

2. 如果是新项目，建议用 GitHub Actions，一站式体验更佳。

参考项目

GitHub Actions：

流水线代码：.github/workflows/laravel-6.yml

运行效果：https://github.com/laravel-fans/laravel-docker/actions

Circle CI：

流水线代码：.circleci/config.yml

运行效果：https://app.circleci.com/pipelines/github/wifidog/wifidog-auth-laravel

Travis CI：

流水线代码：.travis.yml

运行效果：https://travis-ci.com/github/openwrtio/openwrtio.github.io