GitHub Actions 是什么

GitHub 官方号称 Actions 可以让你的工作流自动化：GitHub 监听某个事件（可能是某个分支的提交），然后触发你预定义的工作流，让大家在GitHub服务器上直接测试代码、部署代码。所以，我们可以利用这里特性来做 CI/CD，开发者只要写一下 workflow 脚本就可以了，不用费心思想要用哪个第三方的 CI/CD 服务。

actions 其实就是由一些脚本组成，所以它们是可以复用的，GitHub 做了一个官方市场- https://github.com/marketplace?type=actions
，可以搜索到他人提交的 actions。另外，还有一个 awesome actions 的仓库- https://github.com/sdras/awesome-actions，也可以找到不少的action。这样一来，你甚至都不用自己写具体的脚本，直接引用别人的脚本就行啦。
----------------------

GitHub激动地宣布，终于支持CI/CD了。

CI/CD，全称：持续集成 (Continuous Integration) ，持续部署 (Continuous Deployment) ，是开发流程的自动化利器，如今可以在公有项目上免费使用了。

全面兼容各种操作系统，各种语言，以及各种云。

Actions的角色，是把工作流自动化 (变成代码) ，让大家在GitHub服务器上直接测试代码、部署代码。

微软这一统天下的姿势，也让人感觉到，像CircleCI这样的持续集成工具，可能要凉。就像之前GitHub发布的包管理工具，令NPM瑟瑟发抖那样。

所以，支持了CI/CD的Actions，到底有多强？

海纳百川，高度自动

按官方博客的说法，新的GitHub Actions能把搭建、测试、部署项目的整个流程，更加方便地自动化。

不管你用的是Linux、MacOS还是Windows。

也不管工作流是直接在容器上运行，还是在虚拟机上运行。

广泛支持各种语言和框架：

Node.js，Python，Java，PHP，Ruby，C/C++，.NET，Android以及iOS。

如果，你想测试多容器的复杂应用，现在可以把你的网络服务和数据库一起测试。只要在工作流文件里，加上一些docker-compose就行了。

然后，详细观察一下功能：

矩阵构建 (Matrix Builds)

有了它，你可以把一个项目的许多版本并行测试。

只要在Actions YAML文件里，加上这几行代码：

 1 jobs:
 2   test:
 3     name: Test on node ${{ matrix.node_version }} and ${{ matrix.os }}
 4     runs-on: ${{ matrix.os }}
 5     strategy:
 6       matrix:
 7         node_version: [8, 10, 12]
 8         os: [ubuntu-latest, windows-latest, macos-latest]
 9
10     steps:
11     - uses: actions/checkout@v1
12
13     - name: Use Node.js ${{ matrix.node_version }}
14       uses: actions/setup-node@v1
15       with:
16         version: ${{ matrix.node_version }}
17
18     - name: npm install, build and test
19       run: |
20         npm install
21         npm run build --if-present
22         npm test

剩下的工作，交给GitHub就可以了。

实时日志 (Live Logs)

，可以在你的builds运行过程中，为它们的进程 (Progress) 提供丰富的反馈。

系统会把你的日志传输到Actions控制台，实时显示状态。

 

这个日志功能是为了易读性而定制的，里面还有Emoji。

另外，你也可以用一个简单的永久链接 (Permalink) ，来深度链接(Deep Link) 到任何日志文件

的任意一行。

这样，就很容易和小伙伴讨论一个故障，或者测试结果了。

像写代码那样

action就是代码。所以可以编辑，可以重复使用，可以分享，可以fork。

当你fork了一个项目，就同时fork了它的action，和它的源码。

这是个无缝连接的方法，你可以用跟原始项目同样的action来搭建、测试自己的项目。

团队说，要向社区学习，这是一个很好的办法。你有了喜欢的项目，重现它的每一步，然后fork过来适应自己的需要。

这里用了一种整洁的新语法 (Syntax) 来表达工作流，基于YAML。

你可以重复使用每个action和工作流，引用起来很容易，就像简单的repo reference。

这样，就可以轻松把它们拼接起来，变成强大的工作流。

可以用JavaScript写出来，或者创建一个容器action，两种方法都能通过GitHub API来交互，其他公开API也可以。

还有一个丰富的生态，可以重复利用，它来自GitHub的各路合作伙伴：比如LaunchDarkly、mabl、Code Climate、GitKraden。

甚至，你还可以触发一个CircleCI上的build。

不止一种工作流

除了构建、测试、部署应用，你也可以用GitHub Actions来自动化其他任务：

比如，Issue的分类和管理，自动发布新版本，和你的用户群协作等等。

在GitHub整个开发者周期里、任何一个事件上面，工作流都能被触发。

并且，任何GitHub App都可以添加自定义事件

。这样，开发者和它们的伙伴，就能定制GitHub来满足项目的需求了。

从集成包和容器注册表上构建

包的发布和容器的发布，是CI/CD工作流上的关键部分。

比如开源一个库，比如部署一个大型网络服务。

GitHub Actions让各种包的发布和使用，变得更容易了。

不管是GitHub Package Registry里面的包，还是其他注册表里的包。

开发者能访问Actions了，也就能访问GitHub Package Registry，来自动化整个工作流，从构建到部署。

简单上手

GitHub想让你快点用上CI/CD功能。

于是，一旦你给项目启用了Actions，GitHub就会根据你的项目，匹配一些合适的工作流推荐出来。

所有公开项目都可以免费使用。

而私有项目要用CI/CD，就有价格表了。

CI/CD是到底是什么

看到这里，可能还有一些朋友没有明白：CI/CD

到底是个啥？

CI：Continuous Integration，持续集成，指的是一个团队的所有开发人员每天多次把自己手里的代码合并到主干中去，用一致的自动化方法来构建、打包和测试程序，可以频繁修改代码，提升软件质量，便于团队协作。

CI可以实现自动化测试

，更早拿到测试结果，防止有问题的代码被交付出去，也更容易编译，降低了测试成本和和时间。

CD则有两个概念，一个是Continuous Delivery，持续交付，在CI中构建自动化的测试流程后，持续将代码发布的存储库，不一定部署到生产环境中。

持续交付对于细微的变更十分有用，可以加速迭代过程。

另一个是Continuous Deployment，持续部署，通过自动化的构建、测试和部署循环来快速交付高质量的产品，直接部署到生产环境中，用户可以感受到产品的变化，不需要做专门的发布更新，而是修改之后几分钟就上线了。

持续部署可以使发布频率更高，每次提交自动触发发布流，降低了小批量发布的风险，用户体验也能持续提升，不用每次都等更新。

议论纷纷

原本要靠第三方才能实现的功能，现在GitHub自己就干了，这当然引来了许多程序员的热烈欢迎，没多久，GitHub推特的评论区里欢呼声此起彼伏：Awesome! Cool! Amazing!

不过，之前那些CI工具，可能日子就不好过了。

一大批CI工具面临凉凉

不过，既然GitHub自己出了CI/CD功能，那么以前那些第三方CI工具，大家还会用么？

不少人已经开始挥手拜别了.

也有人看到多系统支持这一点就非常high:

TravisCI、CircleCI这些工具，可能要面临用户流失糟糕状况了。