一、为什么需要持续集成部署

如果你经常写代码，肯定遇到过这种情况：明明在自己电脑上跑得好好的程序，一提交到仓库就各种报错。或者更糟——测试时一切正常，上线后直接崩溃。这种时候，持续集成（CI）和持续部署（CD）就能派上大用场了。

简单来说，持续集成就是每次代码提交后，自动运行测试、构建和检查。而持续部署则是在通过所有检查后，自动将代码发布到生产环境。这样做的好处显而易见：

  1. 快速发现问题：代码提交后立即测试，不用等到上线前才手忙脚乱
  2. 减少人工操作：自动化流程省去了重复劳动
  3. 提高发布质量：每次提交都经过完整验证，降低线上事故概率

对于Rust项目来说，这套流程尤其重要。因为Rust的编译检查非常严格，如果不在CI中提前发现问题，等到部署时可能会被 borrow checker 教做人。

二、GitHub Actions 基础

GitHub Actions 是 GitHub 提供的 CI/CD 服务，它最大的优势就是与 GitHub 深度集成。你只需要在仓库里放个 YAML 配置文件，剩下的交给 GitHub 就行。

一个最基本的 workflow 文件长这样：

# 文件位置：.github/workflows/ci.yml
name: Rust CI

on: [push]  # 触发条件：每次push时运行

jobs:
  build:
    runs-on: ubuntu-latest  # 使用Ubuntu系统运行
    
    steps:
    - uses: actions/checkout@v2  # 第一步：检出代码
    
    - name: Install Rust
      uses: actions-rs/toolchain@v1
      with:
        toolchain: stable  # 安装稳定版Rust
        
    - name: Run tests
      run: cargo test  # 运行测试

这个配置做了三件事：

  1. 检出你的代码
  2. 安装 Rust 工具链
  3. 运行 cargo test

三、进阶配置实战

3.1 矩阵测试

Rust 需要支持多个平台和工具链版本，这时可以用矩阵测试：

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, macos-latest, windows-latest]
        rust: [stable, beta, nightly]
        include:
          - rust: nightly
            features: "--features unstable"
            
    steps:
    - uses: actions/checkout@v2
    
    - name: Install Rust ${{ matrix.rust }}
      uses: actions-rs/toolchain@v1
      with:
        toolchain: ${{ matrix.rust }}
        override: true
        
    - name: Run tests
      run: cargo test ${{ matrix.features }}

这段配置会在 Linux、Mac 和 Windows 上，分别用 stable、beta 和 nightly 三个 Rust 版本运行测试。对于 nightly 版本，还额外启用了 unstable 特性。

3.2 缓存优化

Rust 编译比较耗时，可以通过缓存来加速：

- name: Cache cargo registry
  uses: actions/cache@v2
  with:
    path: |
      ~/.cargo/registry
      ~/.cargo/git
      target
    key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}

这个缓存配置会保存：

  1. Cargo 的包缓存
  2. Git 依赖缓存
  3. 编译目标目录

只要 Cargo.lock 没变，就会复用缓存。实测可以节省 50% 以上的构建时间。

3.3 自动发布

测试通过后，可以自动发布到 crates.io：

- name: Publish to crates.io
  if: github.event_name == 'push' && startsWith(github.ref, 'refs/tags/')
  run: cargo publish --token ${{ secrets.CARGO_TOKEN }}
  env:
    CARGO_REGISTRY_TOKEN: ${{ secrets.CARGO_TOKEN }}

注意：

  1. 只有打 tag 时才会触发发布
  2. 需要提前在仓库 Settings 里配置 CARGO_TOKEN
  3. 建议先在测试环境验证发布流程

四、踩坑指南

4.1 常见问题

  1. 权限不足：
    GitHub Actions 默认没有写入权限，如果要做 push 操作需要配置 token：

    - name: Push changes
  uses: actions-rs/git-push@v1
  with:
    token: ${{ secrets.GITHUB_TOKEN }}

  2. 跨平台问题：
    Windows 和 Unix 的路径分隔符不同，建议使用 std::path::Path 处理路径

  3. 依赖问题：
    某些 crate 需要系统库，比如 OpenSSL，需要在 job 里先安装：

    - name: Install OpenSSL
  if: runner.os == 'Linux'
  run: sudo apt-get install -y libssl-dev

4.2 最佳实践

  1. 分层测试：

    • 单元测试（快速）
    • 集成测试（中等）
    • 端到端测试（慢速）
      分开运行，优先跑快速测试

  2. 超时设置：
    默认超时是6小时，对于小型项目可以设短些：

    jobs:
  test:
    timeout-minutes: 30

  3. 本地验证：
    可以用 act 工具在本地运行 GitHub Actions：

    act -j test

五、总结

通过 GitHub Actions 实现 Rust 项目的 CI/CD 流程，可以显著提高开发效率。从最基本的测试运行，到复杂的多平台矩阵测试，再到自动发布，GitHub Actions 都能很好地支持。

关键点回顾：

  1. 使用矩阵测试确保跨平台兼容性
  2. 合理利用缓存缩短构建时间
  3. 自动化发布流程减少人为失误
  4. 注意权限管理和平台差异

虽然初期配置需要花些时间，但一旦搭建完成，就能享受到自动化带来的便利。特别是对于 Rust 这种编译要求严格的语言，早发现问题就能少掉头发。