自动部署流水线

一条典型的自动部署流水线通常包含以下阶段，全部由 CI/CD 工具（如 GitHub Actions、GitLab CI、Jenkins、CircleCI 等）自动执行：

graph LR
    A[合并到 main] --> B[运行测试]
    B --> C[构建制品]
    C --> D[部署到预生产环境]
    D --> E[运行冒烟测试]
    E --> F[人工确认/自动审批]
    F --> G[部署到生产环境]

各阶段说明

• 运行测试：单元测试、集成测试、静态分析等，确保代码质量。
• 构建制品：打包成 Docker 镜像、JAR 包、静态文件包等。
• 部署到预生产环境：将制品部署到一个与生产环境配置尽量相似但面向内部或非真实流量的环境。
• 运行冒烟测试：快速验证核心功能是否正常，也可以包括性能测试、安全扫描。
• 人工确认/自动审批：根据风险策略，可设置为自动（低风险）或需手动点击“批准部署”按钮。
• 部署到生产环境：通过滚动更新、蓝绿部署、金丝雀发布等方式上线。

生产环境 vs. 预生产环境（Staging）

为什么需要预生产环境？

直接合并到 main 就部署到生产环境风险太高。预生产作为“最后一道防线”，可以在不影响真实用户的情况下发现问题。
许多团队的“立即部署”是指 自动部署到预生产环境，之后经过快速验证（例如 15 分钟）再自动或手动推送到生产。

实现“立即部署”的关键技术

基于 GitHub Actions 的流水线示例

name: Deploy on merge to main

on:
  push:
    branches:
      - main

jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: make test
      - name: Build artifact
        run: make build
      - name: Deploy to staging
        run: ./deploy.sh staging
      - name: Smoke test staging
        run: ./smoke-test.sh staging

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production   # 需要保护规则（如等待批准）
    steps:
      - name: Deploy to production
        run: ./deploy.sh production

• environment: production 可以配置为需要特定角色批准（例如项目负责人点击“确认”）。
• 也可以完全自动：移除 environment 字段，并在 smoke-test 成功后直接调用生产部署脚本。

安全策略：特性开关（Feature Flag）

即使代码合并并自动部署到生产，如果某个新功能尚未准备好对全部用户开放，可以借助特性开关：

• 代码合并到 main → 自动部署 → 功能处于“关闭”状态（只有内部用户或一定百分比流量可见）。
• 在预生产中充分测试后，通过配置中心将开关“打开”给所有用户。 这样既实现了“随时可部署”，又避免了不成熟功能破坏用户体验。

回滚机制

自动部署流水线必须配套快速回滚能力：

• 回滚方式：
  • 重新部署上一个版本的制品（镜像或包）。
  • 使用 Kubernetes 的 rollout undo。
  • 使用云平台的版本回滚（如 AWS CodeDeploy 的回滚）。
• 触发条件：
  • 人工执行 git revert 合并提交，触发新的流水线回滚。
  • 监控系统发现错误率飙升时自动回滚（高级策略）。

适合的场景

• SaaS 产品：单版本线上服务，无遗留版本维护压力。
• 内部工具：用户对短时故障容忍度较高。
• 快速迭代的开源项目：用户乐于拉取最新代码，或项目依赖容器化隔离。

不适合的场景

• 嵌入式/客户端软件：用户不能实时获取更新，需要版本发布周期。
• 金融、医疗等强合规行业：要求严格的变更窗口和审批记录。
• 多版本并行的系统（如同时维护 v1、v2 API）：需要 Git Flow 或基于标签的发布分支。