持续部署到预发布环境

简介

持续部署（CD）是将经过验证的软件交付到可运行环境的阶段。

再想象一下我们的软件工厂：

CI：机器人检查缺陷。
制品：机器人把产品装进盒子。
CD：配送卡车把盒子运到商店（服务器），供客户使用。

在实际环境中，部署通常意味着通过 SSH、API 或平台特定的发布机制更新正在运行的系统。在本实验中，你将模拟这一过程，但需要重点理解的是：如何将经过测试的代码交付到运行环境。

这就是 CI 与 CD 的核心区别。CI 证明软件变更已经足够可靠，可以考虑发布；CD 则负责将这些经过验证的变更以受控方式部署到某个环境中。

在本实验中，你将：

学习手动触发器（点击部署）的概念。
编写一个模拟真实部署过程的工作流。
将「交付卡车」（CD）连接到「质量控制」（CI）。

前提条件

我们将继续使用 github-actions-basics 仓库。

创建手动部署

有时，你不希望每次推送代码时都进行部署。你可能需要等待审批，或者只在准备就绪时部署。

因此，手动触发器和分阶段环境很常见。交付流水线通常需要在速度与运维谨慎之间取得平衡，而不是每次构建成功后都立即部署到生产环境。

GitHub Actions 支持创建仅在点击按钮后才运行的工作流。实现这一点需要使用 workflow_dispatch 触发器。

进入项目目录。

cd ~/project
git clone https://github.com/your-username/github-actions-basics.git
cd github-actions-basics

注意：将 your-username 替换为你实际的 GitHub 用户名。

创建一个名为 deploy.yml 的新文件。

touch .github/workflows/deploy.yml

使用 nano 打开该文件。

nano .github/workflows/deploy.yml

添加以下内容：

name: Deploy to Production

on: workflow_dispatch

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploying
        run: echo "Starting deployment..."

注意 on: workflow_dispatch。这就是手动触发部署的按钮。

保存并退出 nano，然后将该文件推送到 GitHub。

git add .
git commit -m "Add manual deployment workflow"
git push

现在，打开 GitHub 中的 Actions 选项卡。

点击左侧边栏中的 Deploy to Production。
你会看到一个蓝色提示条，其中显示「This workflow has a dispatch event trigger.」。
点击 Run workflow 按钮，然后在下拉菜单中点击绿色的 Run workflow 按钮。

Run workflow

你刚刚手动触发了一个部署流水线！

模拟部署步骤

真实的部署脚本可能很复杂，但通常遵循一个简单的模式：

连接到服务器。
拉取软件的新版本。
重启应用程序。

即使具体实现有所不同，大多数部署流水线仍然遵循这一基本结构：完成身份验证、获取所需制品，并让运行环境使用该制品。

下面更新 deploy.yml，模拟这些步骤。我们将使用 echo 命令显示实际部署中会发生的操作。

再次打开该文件。

nano .github/workflows/deploy.yml

将 jobs 部分替换为以下更详细的模拟内容：

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Mock SSH Connection
        run: echo "Connecting to production server at 192.168.1.1..."

      - name: Pull New Image
        run: |
          echo "Logging into Registry..."
          echo "Pulling image ghcr.io/myname/app:latest..."

      - name: Restart Application
        run: |
          echo "Stopping old container..."
          echo "Starting new container..."
          echo "Deployment Successful!"

保存并退出，然后推送变更。

git add .
git commit -m "Update deployment steps"
git push

返回 GitHub Actions，再次手动运行 Deploy to Production 工作流。查看日志，显示的内容就像真实部署一样！

Run workflow

这种「模拟」技术非常实用。在专业环境中，我们经常先编写这种「骨架」工作流，在实现复杂代码之前先确定流程。

添加安全检查

目前，「Deploy」工作流与「Test」（CI）工作流完全分离。但在实际环境中，你绝不能部署有问题的代码。只有质量检查通过，交付卡车才能出发。

你可以使用 needs 关键词连接工作流，但它最适合在同一个文件中使用。对于不同文件中的工作流，通常通过流程进行管理：CI 在推送时运行，CD 在发布或手动触发时运行。

不过，现在我们来学习如何为手动部署添加安全检查。这里假设只有在完全确认安全的情况下才进行部署。

打开 deploy.yml。

nano .github/workflows/deploy.yml

添加一个 environment 保护模拟。在 steps 中加入暂停步骤。

steps:
  - name: Safety Check
    run: echo " verifying that CI passed..."

  - name: Mock SSH Connection
    run: echo "Connecting to production server at 192.168.1.1..."
  ## ... rest of the file

（注意：在真正的 Enterprise 设置中，我们会使用名为 GitHub Environments 的功能，强制要求「CI 必须通过」后才能运行此作业，但这需要在此文件之外进行配置。）

现在保存并退出，然后推送变更。

git add .
git commit -m "Add safety check"
git push

最后再手动运行一次该工作流。

总结

恭喜你！你已经完成 GitHub Actions CICD 模块。

在这个最后的实验中，你学习了：

手动触发器：如何使用 workflow_dispatch 控制部署。
模拟：如何使用模拟步骤设计部署流程原型。
整体视角：CI、制品、安全性和 CD 如何协同工作。

你从不了解 GitHub Actions 开始，现在已经拥有一个功能完整的仓库，其中包含自动化测试、打包和部署脚本。你已经可以开始自动化自己的项目了！