## 前言
说起自动化，无论是在公司还是我们个人的项目中，都会用到或者编写一些工具来帮助我们去处理琐碎重复的工作，以节约时间提升效率，尤其是我们做前端开发会涉及诸如构建、部署、单元测试等这些开发工作流中重复的事项，本篇文章就是介绍如何利用 GitHub 提供的 Actions 来完成我们前端的发布自动化。
## Github Actions
### 什么是 Actions
笔者个人理解为在某种条件下可被触发的任务，利用一个个任务（Action）就可组建成我们的工作流，想要更详细的介绍定义的同学可以移步 [官方Action定义](https://github.com/features/actions)，有助获取更多的信息，这里就不搬运啦~
### 使用 Actions 的好处
前端自动化部署方案有多种，那么 GitHub 推出的 Actions 有什么魅力呢？在笔者看来，Action 在前端自动化发布有下面 3 点亮点：
- **免费**，Action 可与 GitHub 中的 Repo 进行绑定（下图所示，具体操作见下文），**开箱即用**：这就意味着我们不需要提供跑任务的机器，也不用管怎么把任务流对接起来，只要简单地熟悉规则，就能将项目 run 起来。而我们大部分觉得某个工具麻烦，是因为使用步骤繁琐，若要实现功能 A，还需做 B/C/D 操作才行，这时候我们要么放弃要么转向操作更简单的工具，毕竟省时省事才是开发第一要务~
- **任务插件化**，持续丰富的插件开源市场：得益于 Github 定义了 Actions 规范，让我们使用的 Actions 时都是按某种已知规则开发，这使得 Actions 更易于装配复用，很多优秀的开发者在制作完成工作流后，将自己开发的 Actions 放到 GitHub 的 [Actions 集市](https://github.com/marketplace?type=actions)上去，这样尚未完成自己常规工作流的开发，不需要额外开发这些已有重复逻辑直接使用现成的他人 Actions 即可。在笔者的实践过程中，前端的构建部署工作流，就是用的各类现有的 Actions 组合实现的。
- **和 GitHub 集成好**，可避免因为使用 Travis 等第三方工具引起额外的心智负担，在 GitHub 上可直接查看 CI/CD 的情况。
当然 Actions 还有许多其他好处，还待各位亲自尝试，至少使用过 Actions 的人都说好
