手动测试和部署是程序员生产力的头号杀手。GitHub Actions 免费提供给公开仓库的 CI/CD 能力,足以覆盖大多数个人项目和小型团队的需求。这篇分享一套我在多个项目中验证过的最佳实践。
Workflow YAML 的核心结构
一个标准的 GitHub Actions workflow 文件放在 .github/workflows/ci.yml,由触发器(on)、作业(jobs)和步骤(steps)三部分组成。触发器可以是 push、pull_request 或手动触发(workflow_dispatch)。
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: '3.11'
- run: pip install -r requirements.txt
- run: pytest -v
Matrix Strategy:一次配置,多版本覆盖
当你的库需要同时支持 Python 3.10、3.11、3.12 时,不需要写三个几乎一样的 job。matrix 策略可以自动生成并行任务矩阵,每个组合独立运行:
jobs:
test:
strategy:
matrix:
python-version: ['3.10', '3.11', '3.12']
os: [ubuntu-latest, windows-latest]
runs-on: ${{ matrix.os }}
steps:
- uses: actions/setup-python@v5
with:
python-version: ${{ matrix.python-version }}
# ... 其余步骤
这会生成 6 个并行 job(3 个 Python 版本 × 2 个操作系统)。如果你的测试本身并行度够高,总耗时和最慢的一个 job 差不多。
Cache pip 依赖:让构建飞起来
每次 CI 都从零安装依赖是巨大的浪费。使用 actions/cache 缓存 pip 的安装目录,第二次构建时间可以从 3 分钟降到 30 秒:
- uses: actions/cache@v4
with:
path: ~/.cache/pip
key: ${{ runner.os }}-pip-${{ hashFiles('requirements.txt') }}
restore-keys: |
${{ runner.os }}-pip-
关键点是用 hashFiles('requirements.txt') 做缓存键——依赖文件不变就命中缓存,变了就自动重建。这比盲目设置过期时间要精确得多。
Secrets 管理与 rsync 自动部署
部署步骤需要 SSH 私钥,绝对不能硬编码在 workflow 文件中。在仓库的 Settings → Secrets and variables → Actions 中设置 SSH_PRIVATE_KEY、VPS_HOST 等变量,workflow 中通过 ${{ secrets.SSH_PRIVATE_KEY }} 引用。
- name: Deploy to VPS
run: |
mkdir -p ~/.ssh
echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa
rsync -avz --delete ./dist/ \
deploy@${{ secrets.VPS_HOST }}:/var/www/app/
建议搭配 if: github.ref == 'refs/heads/main' 条件,确保只有 main 分支的推送才触发部署,避免把 feature 分支的代码发到生产环境。另外可以加一个 needs: test 依赖,确保测试全部通过后才执行部署。
总结
一套好的 CI/CD 流水线是「自动化测试 + 缓存加速 + 条件部署」的组合。GitHub Actions 的 matrix 策略和 cache action 能显著缩短反馈循环,secrets 管理让敏感信息不出现在代码中。投入两小时搭建好这些基础设施,未来每次提交都能自动验证,收益远超成本。
※ 全文约 710 字