你知道什么是 GitHub Action 么？

本文是 GitHub Action 的入门教程，如您已有相关使用经验可以直接关掉。

GitHub Action 是 GitHub 于 2018 年 10 月推出的一个 CI\CD 服务。

之前一直都是 Beta 版本，正式版于 2019 年 11 月正式推出。

首先还是先放几个官方的链接：

GitHub Action ： https://github.com/features/actions

GitHub Action 官方市场： https://github.com/marketplace?type=actions

CI\CD

CI\CD 其实说的是三件事情：「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」、「持续部署（Continuous Deployment）」。

因为「持续交付」和「持续部署」的英文缩写是一样的，所以这三件事情缩写成了 CI\CD 。

持续集成

那么什么是「持续集成」？借用一幅图：

从这幅图上可以很清楚的看到「持续集成」的流程：

• 开发人员提交代码到 Source Repository （源代码仓库），并通过 git hook 等
• 触发 CI Server（持续集成服务器）的相关功能。执行 编译 -> 测试 -> 输出结果 的流程
• 向开发人员反馈结果的 report

我们在日常开发中经常使用到的集成方式是「阶段集成」（完成一个阶段的开发后执行代码的集成），相比较而言，「持续集成」能给我们带来的好处有哪些？

• 易于定位错误：每一次的代码集成都需要执行相关的测试工作，持续集成频繁的集成次数天然的*将复杂的代码逻辑切割为了小块，也就使得每一次测试中遇到的错误能够更加容易的被定位；
• 易于控制开发流程：更为细致的工作提交也就意味着更容易判断当前的工作进度，这对于管理者规划开发流程而言提供了一个有效的参考，同时也为开发人员省下了汇报工作的时间；
• 易于 CodeReview：对于大块工作的切分自然也有助于做 CodeReview；
• 易于减少不必要的工作：build 以及 test 过程的自动化可以为你节约一大票的时间，从而投入到有价值的工作中去。

持续交付

什么是持续交付呢？

「持续交付」 指的是：一种能够使得软件在较短的循环中可靠的发布的软件工程方法。

与「持续集成」相比，持续交付的侧重点在于 交付 ，其核心对象不在于代码，而在于可交付的产物。

「持续集成」仅仅针对于新旧代码的集成过程执行了一定的测试，其变动到持续交付后还需要一些额外的流程。

从上面这张图可以看到，与「持续集成」相比较，持续交付 添加了 Test -> Staging -> Production 的流程，也就是为新增的代码添加了一个保证：确保新增的代码在生产环境中是可用的。

在这一增加的流程中，Test 环节不仅仅包含基本的单元测试，还需要延伸到更为复杂的功能测试以及集成测试等。

在这里，Staging 指的是 类生产环境 ，其尽可能的对真实的网络拓扑、数据库数据以及硬件设备等资源进行模拟，从而为测试人员反馈代码在生成环境中的可能表现。

流程中每一个环节的执行结果都会对开发人员进行反馈，每一个出现的错误都会导致版本的回滚。

当测试完毕确认无误之后，将由相关人员对其进行 手动 部署到生产环境。

持续部署

「持续部署」意味着：通过自动化部署的手段将软件功能频繁的进行交付。

与「持续交付」以及「持续集成」相比，「持续部署」强调了通过 automated deployment 的手段，对新的软件功能进行集成。

通过和「持续交付」的图对比，区别主要体现在对 Production 的自动化。

从开发人员提交代码到编译、测试、部署的全流程不需要人工的干预，完全通过自动化的方式执行。

这一策略加快了代码提交到功能上线的速度，保证新的功能能够第一时间部署到生产环境并被使用。

从前面这些介绍可以看到，CI/CD 是由很多操作组成，比如抓取代码、运行测试、登录远程服务器，发布到第三方服务等等。GitHub 把这些操作就称为 actions。

很多操作在不同项目里面是类似的，完全可以共享。GitHub 注意到了这一点，想出了一个很妙的点子，允许开发者把每个操作写成独立的脚本文件，存放到代码仓库，使得其他开发者可以引用。

如果你需要某个 action，不必自己写复杂的脚本，直接引用他人写好的 action 即可，整个持续集成过程，就变成了一个 actions 的组合。这就是 GitHub Actions 最特别的地方。