持续交付

• 持续集成一旦完成，则表示产品处在一个可交付的状态，获取外部对软件的反馈在通过”持续集成”进行优化的过程就叫做”持续交付”，它是“持续集成”的自然延续
• 持续交付的影响因素
  1. 内建质量的组织文化
  2. 审批流程的复杂程度
  3. 系统架构和部署架构
• 持续交付的配置管理
  1. 分支管理
  2. 依赖管理
  3. 代码回滚
• 几个阶段
  1. 触发（Trigger）
     • Pr 被合并到 main 或 release 分支
  2. 执行自动化任务（Github Actions Workflow for CD）
     • 创建版本号（Versioning）
       • 自动化版本管理：基于 Conventional Commits 规范，自动生成 CHANGELOG.md 并利用 standard-version 提升版本号。
       • 创建 Git Tag：为此次发布的 Commit 打上版本标签，如 v1.2.0。
       • 创建 GitHub Release: 自动创建一个包含变更日志和构建产物的 GitHub Release 页面。
     • 构建生产环境产物 (Build for Production)：再次执行构建，但这次使用生产环境的配置。
     • 打包与推送 (Package & Push)：
       • 将构建产物（如 dist 文件夹）推送到对象存储（如 AWS S3, Google Cloud Storage）。
       • （如果使用容器化）构建 Docker 镜像并推送到镜像仓库（如 Docker Hub, GCR, ECR）。
     • 部署到预发环境 (Deploy to Staging)：将构建产物/镜像部署到一个与生产环境完全一致的预发（Staging）服务器。
     • 在预发环境运行端到端测试 (E2E Tests)：使用 Cypress 或 Playwright 对预发环境进行全面的自动化测试，模拟真实用户操作流程。
     • 部署到生产环境 (Deploy to Production)：
       • 手动审批 (持续交付)：在部署到生产前，可以设置一个 manual approval 步骤，由 QA 或产品负责人确认后，再一键触发部署。
       • 自动部署 (持续部署)：如果对自动化测试有足够的信心，E2E 测试通过后，流程将自动部署到生产环境。
       • 采用渐进式发布策略：
         • 蓝绿部署 (Blue-Green Deployment)：部署到一套新的“绿色”环境，测试通过后，将流量瞬间从“蓝色”环境切换到“绿色”。如果出问题，可以立刻切回。
         • 金丝雀发布 (Canary Release)：将新版本只部署到一小部分服务器（例如 5% 的流量），观察监控指标（错误率、延迟）。如果一切正常，逐步扩大流量比例直到 100%。
  3. 最终阶段：监控与回滚 (Monitoring & Rollback)
     • 健康检查 (Health Checks)：部署完成后，自动化脚本应立即检查生产环境的核心功能是否正常（例如访问首页、调用关键 API）。
     • 告警 (Alerting)：集成监控系统（如 Prometheus, Sentry），如果新版本的错误率激增，立即告警。
     • 回滚机制 (Rollback Mechanism)：
       • 自动化回滚：当健康检查失败或关键监控指标异常时，CD 流程应能自动触发回滚，即重新部署上一个稳定的版本。
       • 一键回滚：在 GitHub Actions 或部署平台提供一个“Rollback”按钮，允许开发者在发现问题后，快速手动触发回滚。