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.jsuses: actions/setup-node@v4with:node-version: '20' # 指定 Node 版本cache: 'npm' # 缓存 npm 依赖，加速下次构建# Step 3：安装项目依赖- name: Install dependenciesrun: npm ci # npm ci 比 npm install 更严格，适合 CI 环境# Step 4：运行测试（假设项目有 test 脚本）- name: Run testsrun: npm test# 任务2：构建（依赖 test 任务，只有 test 成功才执行）build:needs: test # 依赖 test 任务，test 成功后才执行 buildruns-on: ubuntu-lateststeps:- uses: actions/checkout@v4- name: Use Node.jsuses: actions/setup-node@v4with:node-version: '20'cache: 'npm'- name: Install dependenciesrun: npm ci- name: Build projectrun: npm run build # 假设项目有 build 脚本（如 React/Vue 项目的打包）# Step 5：上传构建产物（可选，方便后续部署）- name: Upload build artifactsuses: actions/upload-artifact@v4with: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: truedefault: 'test'type: choiceoptions:- 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-lateststeps:- uses: actions/checkout@v4- name: Setup Node.jsuses: actions/setup-node@v4with:node-version: '20'cache: 'npm'- run: npm ci- name: Lint coderun: npm run lint # 执行 ESLint 等代码检查- name: Run unit testsrun: npm run test:unit # 执行单元测试- name: Buildrun: npm run build- name: Upload builduses: actions/upload-artifact@v4with:name: frontend-buildpath: dist/
2. 场景 2：自动部署到 GitHub Pages（前端静态页面）
前端打包后的静态文件（如 dist 目录），自动部署到 GitHub Pages，实现 “提交代码→自动上线”：
name: Deploy to GitHub Pages
on:push:branches: [main] # 只有推送到 main 分支才部署jobs:deploy:runs-on: ubuntu-lateststeps:- uses: actions/checkout@v4- name: Setup Node.jsuses: actions/setup-node@v4with:node-version: '20'cache: 'npm'- run: npm ci- run: npm run build # 打包生成静态文件# 部署到 GitHub Pages（使用官方 Action）- name: Deploy to GitHub Pagesuses: peaceiris/actions-gh-pages@v4with:# 授权令牌：需要在 GitHub 仓库设置中创建 Personal Access Token（PAT），并添加到 Secretsgithub_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-lateststeps:- uses: actions/checkout@v4- name: Setup Node.jsuses: actions/setup-node@v4with:node-version: '20'cache: 'npm'- run: npm ci- run: npm test # 执行后端单元测试deploy:needs: test # 依赖 test 任务，测试通过才部署runs-on: ubuntu-lateststeps:- uses: actions/checkout@v4# 通过 SSH 连接到云服务器，执行部署命令- name: Deploy to serveruses: appleboy/ssh-action@master # 社区 SSH Actionwith:host: ${{ secrets.SERVER_HOST }} # 服务器 IP（在仓库 Secrets 中配置）username: ${{ secrets.SERVER_USER }} # 服务器用户名（如 root）key: ${{ secrets.SERVER_SSH_KEY }} # 服务器 SSH 私钥（在 Secrets 中配置）# 部署命令（根据项目实际情况修改，如拉取代码、安装依赖、重启服务）script: |cd /path/to/your/projectgit pull origin mainnpm cipm2 restart app # 假设用 pm2 管理 Node.js 服务
四、关键注意事项
- Secrets 管理：敏感信息（如服务器 IP、SSH 私钥、API 密钥）不能直接写在配置文件中，需在 GitHub 仓库的 Settings → Secrets and variables → Actions → New repository secret 中添加，配置文件中通过
${{ secrets.秘钥名 }}引用。 - Runner 资源限制：GitHub 提供的免费 Runner 有资源限制（如 CPU 2 核、内存 7GB、磁盘空间 14GB），且有使用时长限制（免费账户每月 2000 分钟），复杂项目可考虑使用自己的服务器作为 “自托管 Runner”。
- 调试技巧：若 Workflow 执行失败，可在 GitHub 仓库的 Actions 页面点击对应任务，查看每一步的日志（
Run ...下方的 “View log”），定位错误原因（如依赖安装失败、命令写错）。 - Action 选择：优先使用官方或社区高星的 Action（如
actions/checkout、actions/setup-node），避免使用低星、无维护的 Action，减少安全风险。
五、总结
- CI/CD 核心：通过自动化实现 “代码提交→测试→部署” 的闭环，减少人工成本，降低风险。
- GitHub Actions 优势：与 GitHub 仓库深度集成，配置简单（YAML 文件），无需额外搭建环境，社区 Action 丰富，适合中小型项目快速落地 CI/CD。
- 入门路径：先从简单的 CI 流程（如代码提交触发测试 + 构建）开始，熟悉配置逻辑后，再逐步扩展到 CD 流程（如自动部署到测试 / 生产环境）。