持续集成（CI）：
- 频繁合并（每天多次）
- 自动化构建和测试
- 快速反馈（< 10 分钟）
- 主分支始终可发布

持续交付（CD）：
- 自动化部署到预发布
- 手动触发生产部署
- 一键部署能力
- 可回滚

持续部署：
- 自动化部署到生产
- 每次通过测试的代码都部署
- 需要强大的监控和回滚

Google 的发布流程：

1. 代码提交
   → 自动测试
   → 代码审查
   → 合并到主分支

2. 发布候选
   → 从主分支创建发布分支
   → 运行完整测试套件
   → 生成发布候选版本

3. 金丝雀发布
   → 部署到 1% 的流量
   → 监控错误率和性能
   → 持续 1-24 小时

4. 逐步推广
   → 1% → 5% → 25% → 100%
   → 每步监控指标
   → 问题自动回滚

5. 完全发布
   → 100% 流量
   → 持续监控
   → 旧版本保留用于回滚

版本策略：

1. 语义化版本（SemVer）
   - MAJOR.MINOR.PATCH
   - 不兼容变更 → MAJOR
   - 新功能 → MINOR
   - Bug 修复 → PATCH

2. 日历版本
   - Ubuntu: 22.04（2022年4月）
   - 适合定期发布

3. 提交哈希
   - 每次构建唯一标识
   - 适合持续部署

Google 的版本策略：
- 内部使用提交哈希
- 外部 API 使用语义化版本
- 服务使用日历版本

回滚原则：

1. 快速回滚
   - 回滚应该比修复更快
   - 一键回滚能力

2. 安全回滚
   - 数据库变更需要向前兼容
   - 回滚不应该丢失数据

3. 回滚测试
   - 定期测试回滚流程
   - 确保回滚可用

回滚类型：
- 代码回滚：部署旧版本
- 配置回滚：恢复旧配置
- 数据回滚：恢复旧数据（困难）

# .github/workflows/ci.yml
name: CI/CD

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

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: make test
      - run: make lint

  deploy-staging:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - run: make deploy-staging

  canary:
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
      - run: make deploy-canary
      - run: sleep 300    # 监控 5 分钟
      - run: make check-canary

  promote:
    needs: canary
    runs-on: ubuntu-latest
    steps:
      - run: make deploy-production