用 GitHub Actions 解释 CI/CD 流水线

DevOps2026-09-12TryQuickToolBox

你刚刚推送了一个提交，现在正在手动运行测试、构建应用，并将文件上传到服务器。虽然可行，但速度慢、容易出错，而且无法扩展。这就是 CI/CD 流水线发挥作用的地方。

在本指南中，我们将分解 CI/CD 概念，并向你展示如何使用 GitHub Actions 构建一个真实的流水线。到最后，你将了解如何为任何项目自动化测试、构建和部署。

什么是 CI/CD？

CI（持续集成）是自动测试代码变更并将其合并到共享分支的实践。每次推送都会触发构建和测试运行，及早发现集成问题。

CD（持续交付/持续部署）扩展了 CI，通过自动准备（并可选地部署）你的应用到生产环境。持续交付意味着代码始终准备好部署；持续部署意味着它会自动部署。

CI/CD 共同构成一个流水线：一系列自动化步骤，将你的代码从提交带到生产环境。

为什么使用 GitHub Actions 进行 CI/CD？

GitHub Actions 是内置于 GitHub 的 CI/CD 平台。对公共仓库免费，并为私有仓库提供充足的分钟数。主要优势：

集成性：无需外部服务；工作流位于你的仓库中。
事件驱动：在推送、拉取请求、计划或手动触发时触发工作流。
可扩展：GitHub Marketplace 中有数千个预构建的 action。
矩阵构建：轻松跨多个操作系统和语言版本进行测试。

GitHub Actions 的核心概念

在编写第一个工作流之前，请理解以下术语：

术语	描述
工作流	在 `.github/workflows/` 下的 YAML 文件中定义的自动化流程。
事件	启动工作流的触发器（例如 `push`、`pull_request`）。
作业	在同一运行器上运行的一组步骤。作业默认并行运行。
步骤	作业中的单个任务。可以运行命令或使用 action。
Action	可重用的代码单元（例如 `actions/checkout`），你可以将其包含在步骤中。
运行器	执行作业的虚拟机（Ubuntu、Windows、macOS）。

构建你的第一个 CI 流水线

让我们为 Node.js 项目创建一个基本的 CI 工作流。它将在每次推送到主分支和拉取请求时运行测试。

创建 .github/workflows/ci.yml：

name: CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [18.x, 20.x]

    steps:
    - uses: actions/checkout@v4
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.node-version }}
    - run: npm ci
    - run: npm test

此工作流：

在推送到 main 和 PR 时触发。
在最新的 Ubuntu 运行器上运行名为 test 的作业。
使用矩阵针对 Node.js 18 和 20 进行测试。
检出代码、设置 Node、安装依赖并运行测试。

推送此文件并观察 Actions 选项卡。你会看到两个并行作业（每个 Node 版本一个）。如果任何测试失败，工作流将失败，GitHub 会通知你。

添加持续部署

CI 很棒，但 CD 才是自动化真正闪耀的地方。让我们扩展工作流，在 main 分支上的测试通过后部署到服务器。

我们将添加一个 deploy 作业，它依赖于 test 并且仅在推送到 main 时运行。

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4
    - name: Deploy to server
      uses: appleboy/ssh-action@v1.0.0
      with:
        host: ${{ secrets.SSH_HOST }}
        username: ${{ secrets.SSH_USER }}
        key: ${{ secrets.SSH_KEY }}
        script: |
          cd /var/www/myapp
          git pull origin main
          npm ci --production
          pm2 restart myapp

关键点：

needs: test 确保仅在测试通过时运行部署。
if 条件将部署限制为对 main 的推送。
机密（SSH_HOST、SSH_USER、SSH_KEY）存储在 GitHub 仓库设置中，并安全地注入。

此模式适用于许多部署目标：SSH、Docker 注册表、云平台（AWS、Vercel、Netlify）或 Kubernetes。

使用 GitHub Actions 进行 CI/CD 的最佳实践

保持工作流快速：缓存依赖项（例如 actions/cache）以减少构建时间。
快速失败：在较慢的测试之前运行快速检查（linting）。
使用环境：为生产部署配置保护规则。
保护机密：切勿硬编码凭据；使用 GitHub Secrets。
监控和告警：为失败的工作流设置通知。

调试失败的工作流

当工作流失败时，GitHub 会显示每个步骤的日志。常见问题包括：

缺少依赖项：确保在测试之前运行 npm ci 或等效命令。
机密不正确：仔细检查名称和值。
权限错误：验证运行器权限和 SSH 密钥。

你还可以通过将仓库机密 ACTIONS_STEP_DEBUG 设置为 true 来启用调试日志记录。

常见问题

CI 和 CD 有什么区别？

CI 自动化测试和代码变更的集成。CD 自动化将这些变更交付或部署到环境。CI 确保代码质量；CD 确保它快速可靠地到达用户手中。

GitHub Actions 免费吗？

GitHub Actions 对公共仓库免费。对于私有仓库，你每月有免费分钟数（例如，免费账户 2,000 分钟），超出部分需付费。自托管运行器也是一种选择。

我可以将 GitHub Actions 用于非 GitHub 项目吗？

是的，GitHub Actions 可以运行任何命令行工具。你可以使用它来构建和部署托管在其他地方的项目，只要代码在 GitHub 上或你使用 action 获取它。

准备好简化你的 CI/CD 了吗？从使用 GitHub Actions 自动化测试开始。为了快速分析部署日志，试试我们的 Nginx 日志分析器，在每次部署后发现错误和性能问题。