为什么大佬都在用 Github Actions 做 CICD？

UP主: Hucci写代码 · 时长: 10:02 · 🔗 B站原视频

标签: GitHub Actions · CI/CD · 自动化部署 · 编程开发

什么是 CI/CD 与 GitHub Actions

如果你留意过那些很多 star、很受欢迎的 GitHub 仓库，在 Actions 的标签页下面会有很多失败或者成功的 workflow。你可能会好奇这些 workflow 是干嘛的。事情要从更改代码开始，当项目的代码变更了，就得测试这个更改有没有问题。没问题的话，就合并到主分支；如果有需要的话，还得将代码部署到服务器上。

在这个流程中，除了每次变更的代码有点不一样，后面每个步骤每次总是一样的。于是我们不得不做着大量重复工作，而程序员最讨厌的就是重复工作。为了解决这个问题，CI/CD 出现了。CI（Continuous Integration）持续集成，指的是代码更改持续地集成到仓库中；而 CD（Continuous Delivery）持续交付，指的是让仓库中的代码持续地交付到测试环境或者生产环境中。今天我们就来介绍如何使用 GitHub Actions 来完成 CI/CD，让你的项目也能像那些厉害的项目一样自动集成和交付。

创建第一个测试 Workflow (CI)

我准备了一个示例项目，你可以在视频简介找到链接。让我们在编辑器中打开它。我们需要在项目中新建一个目录叫做 .github，用来存放所有跟 GitHub 相关的东西。然后再在这个 .github 目录下新建一个目录叫做 workflows，用来存放 workflow。当我们想要新建一个 workflow，就在这个目录下创建一个 YAML 文件。

现在我们新建一个 workflow，用来对每次的代码改动进行测试，那这个 workflow 就叫做 test.yml。我们要在这个文件里写三个东西：这个 workflow 叫什么、它要在什么时间、做什么事情。使用 name 给这个 workflow 起个名字，它就叫 test。

配置 Workflow 的触发时机

然后使用 on 来表示这个 workflow 要在什么时候触发。触发的时机有很多种类型，比如说 push 的时候、提交 PR 的时候、创建 issue 的时候，还可以是定时触发。基本上你在 GitHub 做的所有事情都可以成为触发 workflow 的事件，你可以在文档中找到更多类型，我将文档链接放到了视频简介。

当我们在 on 里写了多个时机的时候，只要满足其中一条就会触发 workflow。考虑到我们这个 workflow 是用于测试代码，那我们的时机应该仅仅是 push 和 pull request。但我们不会希望任何一条分支在 push 或者提交 PR 的时候都执行这个 workflow，我们只希望 main 分支会执行，所以我们要增加一个过滤条件，在下面写 branches，然后增加 main 分支。

pull request 也是同样，对于 PR 来说，PR 有好多种行为，可能是开启一个 PR 或者关掉一个 PR。我只想限定是开启的时候，所以我要再限定它的类型是开启。这样就完成了触发时机的设定，它可以是 push 到 main 分支的时候，也可以是对 main 分支开启一个 PR 的时候，只要满足其中任一个条件，这个 workflow 就会被触发。

定义运行任务 (Jobs) 与环境

接下来我们定义这个 workflow 要做什么事。我们需要一个键名叫做 jobs，一个 job 就是 workflow 要执行的一组任务。这个 workflow 要执行代码测试，所以我们的 job 就叫做 test。

使用 runs-on 说明我们这个 job 要在什么样的虚拟机上跑。在大部分情况下，Ubuntu 都是很好的选择，但如果你有特殊需求，你也可以使用 macOS 或者是 Windows。如果你需要一些基本的环境，比如 Node.js、Python、Go，你可以试试一个容器，这样就不用再在虚拟机上安装了。因为我这是一个 Python 项目，所以我需要使用一个 uv 的 container，它是一个 Python 项目管理器，我在之前的视频中介绍过。当然如果你是 Node 项目就写 Node，如果你是 Go 项目就写 Go 都可以。

编写执行步骤 (Steps)

现在我们就要分步骤说明要怎么样测试代码。你可以先想我们怎么在本地测试代码的，差不多就是先将代码拉下来，然后安装依赖，跑下测试，没问题的话就合并了。所以第一个 step 是获取代码。step 可以是一个命令或者别人封装好的 workflow。在 GitHub 的市场里我们可以看到很多，比如这里的 checkout 就会是我们的第一个 step，可以让我们获取代码。使用 uses 就可以使用这个 workflow 了。其实 name 这个属性可以不填，但如果你希望以后的你还能读懂现在在做什么，最好还是写上。这个地方的每一个 step 它都是一个列表的 item，所以我这里需要把它用列表的形式。

下一步是安装依赖。这里我们使用的是 run 而不是前面的 uses，表示我们要执行一个命令，而不是使用一个封装好的 action。因为这是 Python 的项目，所以我使用 uv sync 来安装依赖。如果你是 Node 项目，你就可以使用 npm ci；如果是 Go 项目就可以使用 go mod download。总之随着你的项目来使用不同的命令。

下一步是测试代码，使用 pytest 进行测试。同样，如果你是 Node 项目就用 npm test，如果是 Go 项目就用 go test，总之什么项目就用什么测试方法。这样我们就完成了一个 job 的定义。实际上我还可以写更多的 job，比如说写个 test2 什么的。如果说我们定义了多个 job，那么这两个 job 会并行运行，而不是按照先后顺序运行。但我们的需求是一个 job 就够了，所以就到这里吧。

运行与调试 Workflow

我们将这个 workflow push 到 GitHub 仓库上去。好，现在回到我们的 GitHub 页面，看看 Actions。这里已经出现一个 workflow 了，是刚刚运行的，有个叉叉表示失败了。点进去看看，显示我的 pull request 写错了。确实这里有一个拼写错误，我记错了，是没有 s 的。

好，那我们再一次 push 上去看看。回到页面刷新一下，可以看到 workflow 已经在运行我们刚刚的 commit 了。点开看看，这是我们的 job，显示依然失败了。我们点进去可以查看每个 step 为什么失败。OK，它失败的原因是因为它没有找到测试代码，因为我在创建这个示例的时候忘了写测试代码。但这不重要，我们成功地创建了一个 workflow，这才是最重要的。现在我们就完成了我们 CI/CD 中的 CI。

创建持续交付 Workflow (CD)

接下来我们再来写一个 CD 的 workflow。同样在 workflows 下创建一个 YAML 文档叫做 deploy.yml。同样跟刚刚一样，先写一个 name，然后写它触发的时机。

正常的触发时机我们可以跟刚刚一样，是每当有 push 或者开启 PR 的时候。但如果你希望更严格一点，不要一有代码更改就马上部署，那我们可以将触发的条件改成当我们 push 一个以 v 开头的 tag 的时候，比如说 v1.0、v2.0 什么的。push 这样的一个 tag 就表示你要发版了。

接着是 jobs，我们设置一个 job 叫做 deploy，同样选择 Ubuntu。想想我们部署的流程，如果是在本地的话，那么先将代码拉下来放到服务器上，然后再到服务器上启动服务。我们就按这个流程来。这时候我们就不需要使用容器了，因为我们并不需要运行什么东西，我们只是简单地把代码拉下来，然后放到服务器上。

配置部署步骤与敏感信息 (Secrets)

我们直接写 steps。首先第一步依然是使用 checkout 来获取代码，然后将代码放到服务器上。如果你对 shell 命令很熟的话，你可以直接写 scp 命令。但我每次都得查各种参数的用法，所以我选择直接去市场找一个 action 来做这件事。

使用 scp action 我们需要添加一些参数，比如说服务器的 IP，还有用户名和密码。这样的敏感信息我们肯定不能直接写在代码里。在仓库的 Settings 下面的 Secrets 里面，我们在这里添加一个 secret。这个 secret 的名字叫做 SERVER_HOST，然后在这里填写你的敏感信息添加过去。

添加完成后，我们就可以直接在这里用了。像这个地方我们就可以填写，然后给它加上两个大括号，前后还要一个空格，而且前面再加个美元符号，这样子我们就可以提取我们刚刚使用的 secrets。username 和 key 也是一样的道理。然后再写一下原位置和目标位置，表示我们要从现在的那个位置搬到服务器上的那个位置。

最后在服务器上启动服务。朋友，如果你很熟悉 shell 命令，那么你可以直接用 run 来写命令就好了，但我喜欢使用 action 来完成。同样传入参数，然后说明需要的脚本，cd 到对的位置运行我的脚本。这样子我们就写好了一个 CD 的 workflow。

总结

那么现在你应该能够理解什么是 CI/CD，并使用 GitHub Actions 完成 CI/CD 了。你可以到你的仓库中去尝试使用 GitHub Actions 来做 CI/CD。即使你的项目不需要部署，那也完全可以使用 GitHub Actions 来做 CI。赶紧试试吧！感谢你的观看，我们下次再见。