CI/CD 基础与 GitHub Actions 总结

CI（持续集成，Continuous Integration）和 CD（持续部署 / 交付，Continuous Deployment/Delivery）是现代开发流程的核心实践，目标是通过自动化减少人工操作、降低风险，实现 "代码提交→测试→部署" 的高效流转。GitHub Actions 是 GitHub 内置的 CI/CD 工具，无需额外搭建环境，可直接基于代码仓库配置自动化流程，是入门 CI/CD 的优选方案。

一、CI/CD 核心概念

先明确 CI/CD 的基础定义，理解自动化流程的核心价值：

术语	核心目标	关键动作
CI（持续集成）	频繁将开发者的代码提交合并到 "主分支"，通过自动化测试验证代码正确性，提前发现冲突 / Bug	代码提交触发 → 自动化构建（编译、打包）→ 自动化测试（单元测试、 lint 等）→ 反馈结果
CD（持续交付）	经过 CI 验证的代码，自动部署到 "测试 / 预发布环境"，人工确认后再发布到生产环境	CI 完成后 → 自动部署到测试环境 → 人工审批 → 手动触发生产部署
CD（持续部署）	经过 CI 验证的代码，无需人工干预，直接自动部署到生产环境（更激进的交付方式）	CI 完成后 → 自动部署到测试环境 → 自动验证 → 自动部署到生产环境

核心价值：减少人工操作成本、降低 "手动部署出错" 风险、缩短从代码开发到上线的周期（如 "提交代码后 10 分钟自动部署到测试环境"）。

二、GitHub Actions 基础

GitHub Actions 是 GitHub 原生支持的 CI/CD 工具，所有配置通过代码仓库中的 YAML 文件定义，无需额外服务器。

1. 核心概念（理解配置逻辑）

在编写 GitHub Actions 配置前，需先掌握几个关键术语：

术语	定义
Workflow（工作流）	一个完整的自动化流程（如 "代码提交后执行测试 + 构建"），每个 Workflow 对应一个 YAML 配置文件
Job（任务）	一个 Workflow 由多个 Job 组成，Job 之间可配置依赖关系（如 "先执行测试 Job，再执行构建 Job"）
Step（步骤）	一个 Job 由多个 Step 组成，Step 是具体的执行单元（如 "安装依赖""运行测试命令""上传构建产物"）
Action（动作）	可复用的 Step 模块（如 "安装 Node.js""部署到 GitHub Pages"），可直接使用官方 / 社区现成 Action，无需重复写脚本
Runner（运行器）	执行 Workflow 的环境（GitHub 提供免费的 Linux/macOS/Windows 虚拟机，也可配置自己的服务器作为 Runner）

2. 配置文件规则（入门关键）

GitHub Actions 的配置文件需放在代码仓库的固定目录：/.github/workflows/，文件名以 .yml 或 .yaml 结尾（如 ci-test.yml）。

配置文件基本结构（示例：Node.js 项目的 CI 流程）

# 1. 工作流名称（自定义，将显示在 GitHub 仓库的 Actions 页面）
name: Node.js CI

# 2. 触发条件：什么时候执行这个工作流
on:
  # 当代码 push 到 main 分支时触发
  push:
    branches: [ "main" ]
  # 当向 main 分支提交 Pull Request 时触发
  pull_request:
    branches: [ "main" ]

# 3. 定义该工作流包含的任务（Jobs）
jobs:
  # 任务1：测试（任务名自定义，如 test）
  test:
    # 执行该任务的 Runner 环境（选择 Linux 虚拟机，免费且高效）
    runs-on: ubuntu-latest

    # 该任务的具体步骤（Steps）
    steps:
    # Step 1：从代码仓库拉取代码（官方 Action，无需修改）
    - uses: actions/checkout@v4

    # Step 2：安装 Node.js（使用社区 Action，指定 Node 版本）
    - name: Use Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '20'  # 指定 Node 版本
        cache: 'npm'        # 缓存 npm 依赖，加速下次构建

    # Step 3：安装项目依赖
    - name: Install dependencies
      run: npm ci  # npm ci 比 npm install 更严格，适合 CI 环境

    # Step 4：运行测试（假设项目有 test 脚本）
    - name: Run tests
      run: npm test

  # 任务2：构建（依赖 test 任务，只有 test 成功才执行）
  build:
    needs: test  # 依赖 test 任务，test 成功后才执行 build
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Use Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '20'
        cache: 'npm'
    - name: Install dependencies
      run: npm ci
    - name: Build project
      run: npm run build  # 假设项目有 build 脚本（如 React/Vue 项目的打包）
    
    # Step 5：上传构建产物（可选，方便后续部署）
    - name: Upload build artifacts
      uses: actions/upload-artifact@v4
      with:
        name: build-output  # 产物名称（自定义）
        path: dist/         # 构建产物的目录（根据项目实际情况修改，如 dist、build）

3. 常用触发条件（on 配置）

除了上述示例中的 push 和 pull_request，还有其他常见触发场景：

on:
  # 1. 定时触发（如每天凌晨2点执行，适合定时测试/备份）
  schedule:
    - cron: '0 2 * * *'  # cron 表达式：分 时 日 月 周（UTC 时间）
  
  # 2. 手动触发（在 GitHub Actions 页面点击"Run workflow"）
  workflow_dispatch:
    # 可选：手动触发时可传参数
    inputs:
      environment:
        description: '部署环境'
        required: true
        default: 'test'
        type: choice
        options:
          - test
          - prod
  
  # 3. 当其他工作流完成时触发
  workflow_run:
    workflows: ["Node.js CI"]  # 其他工作流的名称
    types:
      - completed

三、GitHub Actions 典型场景实战

掌握基础配置后，结合实际场景理解如何落地 CI/CD：

1. 场景 1：前端项目 CI（测试 + 构建）

如 Vue/React 项目，提交代码后自动执行 lint、单元测试、打包，确保代码质量：

name: Frontend CI
on:
  push: [main, develop]
  pull_request: [main, develop]

jobs:
  lint-test-build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - name: Lint code
        run: npm run lint  # 执行 ESLint 等代码检查
      - name: Run unit tests
        run: npm run test:unit  # 执行单元测试
      - name: Build
        run: npm run build
      - name: Upload build
        uses: actions/upload-artifact@v4
        with:
          name: frontend-build
          path: dist/

2. 场景 2：自动部署到 GitHub Pages（前端静态页面）

前端打包后的静态文件（如 dist 目录），自动部署到 GitHub Pages，实现 "提交代码→自动上线"：

name: Deploy to GitHub Pages
on:
  push:
    branches: [main]  # 只有推送到 main 分支才部署

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run build  # 打包生成静态文件
      
      # 部署到 GitHub Pages（使用官方 Action）
      - name: Deploy to GitHub Pages
        uses: peaceiris/actions-gh-pages@v4
        with:
          # 授权令牌：需要在 GitHub 仓库设置中创建 Personal Access Token（PAT），并添加到 Secrets
          github_token: ${{ secrets.GITHUB_TOKEN }}  # GitHub 自动生成的临时令牌，无需手动创建
          publish_dir: ./dist  # 要部署的目录（打包后的静态文件目录）

3. 场景 3：后端项目 CI/CD（测试 + 部署到服务器）

如 Node.js/Java 后端项目，提交代码后自动测试，测试通过后部署到云服务器（如阿里云、AWS）：

name: Backend CI/CD
on:
  push: [main]
  pull_request: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm test  # 执行后端单元测试

  deploy:
    needs: test  # 依赖 test 任务，测试通过才部署
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      # 通过 SSH 连接到云服务器，执行部署命令
      - name: Deploy to server
        uses: appleboy/ssh-action@master  # 社区 SSH Action
        with:
          host: ${{ secrets.SERVER_HOST }}  # 服务器 IP（在仓库 Secrets 中配置）
          username: ${{ secrets.SERVER_USER }}  # 服务器用户名（如 root）
          key: ${{ secrets.SERVER_SSH_KEY }}  # 服务器 SSH 私钥（在 Secrets 中配置）
          # 部署命令（根据项目实际情况修改，如拉取代码、安装依赖、重启服务）
          script: |
            cd /path/to/your/project
            git pull origin main
            npm ci
            pm2 restart app  # 假设用 pm2 管理 Node.js 服务

四、关键注意事项

1. Secrets 管理 ：敏感信息（如服务器 IP、SSH 私钥、API 密钥）不能直接写在配置文件中，需在 GitHub 仓库的 Settings → Secrets and variables → Actions → New repository secret 中添加，配置文件中通过 ${``{ secrets.秘钥名 }} 引用。
2. Runner 资源限制：GitHub 提供的免费 Runner 有资源限制（如 CPU 2 核、内存 7GB、磁盘空间 14GB），且有使用时长限制（免费账户每月 2000 分钟），复杂项目可考虑使用自己的服务器作为 "自托管 Runner"。
3. 调试技巧 ：若 Workflow 执行失败，可在 GitHub 仓库的 Actions 页面点击对应任务，查看每一步的日志（Run ... 下方的 "View log"），定位错误原因（如依赖安装失败、命令写错）。
4. Action 选择 ：优先使用官方或社区高星的 Action（如 actions/checkout、actions/setup-node），避免使用低星、无维护的 Action，减少安全风险。

五、总结

• CI/CD 核心：通过自动化实现 "代码提交→测试→部署" 的闭环，减少人工成本，降低风险。
• GitHub Actions 优势：与 GitHub 仓库深度集成，配置简单（YAML 文件），无需额外搭建环境，社区 Action 丰富，适合中小型项目快速落地 CI/CD。
• 入门路径：先从简单的 CI 流程（如代码提交触发测试 + 构建）开始，熟悉配置逻辑后，再逐步扩展到 CD 流程（如自动部署到测试 / 生产环境）。