多分支自动化部署需严格按git flow分支语义映射交付阶段：feature/仅构建测试不部署，develop部署dev环境，release/部署staging并强制审批，main部署prod并打semver标签，hotfix/*直连prod且自动合回develop。
多分支自动化部署不是简单地“让每个分支都跑一遍CI”，而是围绕 Git Flow 的分支语义，把构建、测试、发布动作与分支生命周期严格对齐。关键在于：不同分支触发不同阶段的流水线，且部署目标环境明确隔离。
明确各分支的部署职责
Git Flow 的每类分支天然对应一个交付阶段，自动化部署必须按此映射：
- feature/* 分支：仅触发构建 + 单元测试 + 静态扫描，**不部署**。可选部署到临时预览环境（如 Vercel/Netlify 风格的 PR Preview），供开发自测和 UI 评审，但不接入正式测试流程。
- develop 分支：每日或每次合并后触发完整流水线，构建、全量单元测试、集成测试、E2E 测试，**部署到开发环境（dev）**。该环境供内部功能联调使用，版本不稳定但最新。
- release/* 分支：创建时即触发预发布流水线，包含构建、回归测试（覆盖率 ≥85%）、安全扫描、性能基线比对，**部署到预发环境（staging 或 pre-pro）**。测试通过后，才允许合并至 main 并打 tag。
- main 分支：仅接受 release/* 或 hotfix/* 的合并，触发生产就绪流水线（含签名、镜像打包、灰度配置检查），**部署到生产环境（prod）**，并自动打带语义化版本号的 tag（如 v2.3.0）。
- hotfix/* 分支：从 main 切出，流水线跳过部分耗时测试（如 E2E），重点执行快速验证和冒烟测试，**直连 prod 环境部署**，同时自动合并回 develop（避免遗漏修复）。
CI/CD 流水线需按分支动态路由
不能为所有分支写同一套脚本，而应由 CI 工具（如 GitHub Actions、GitLab CI、Jenkins）根据 GIT_BRANCH 或 GITHUB_HEAD_REF 等变量判断分支类型，启用对应阶段：
- 用正则匹配分支名：例如
^feature\/.*$→ 执行轻量流水线；^release\/v[0-9]+\.[0-9]+\.[0-9]+$→ 启动预发布流水线。 - 禁止 feature 分支向任何共享环境（dev/staging/prod）直接部署，防止污染；若需预览，用唯一 URL（如
https://feat-login-abc123.example.com）隔离资源。 - release 分支部署前强制人工审批（如测试负责人 Approve），main 分支部署前增加「生产变更窗口」校验（如只允许工作日 10:00–17:00）。
环境与配置分离是稳定前提
多分支并行部署最大的风险是环境混用或配置错位。必须做到：
- 每个环境（dev/staging/prod）有独立的域名、数据库、缓存实例、API 网关路由规则，互不共享。
- 配置不硬编码在代码中，统一通过环境变量或配置中心注入。例如：前端构建时传入
VUE_APP_API_BASE=//api.staging.example.com，后端启动时加载spring.profiles.active=staging。 - release 分支构建产物需携带分支标识（如
build-release-2.3.0-20260611-abc123），避免覆盖 staging 上其他 release 的部署包。
合并与回滚要可追溯、可反向
自动化部署不是单向操作，必须配套闭环机制：
- 每次成功部署到 staging 或 prod，自动在对应 commit 上创建部署注释（Deployment Annotation），记录流水线 ID、部署人、环境、时间戳。
- main 分支上每个 tag 对应一次生产发布，tag 名严格遵循 SemVer（如
v2.3.0），并关联 Jira Issue 或 PR 列表。 - 支持一键回滚：点击某次 prod 部署记录，自动拉取该 tag 对应的镜像或构建包，重新部署——无需重新构建，也不依赖当前代码状态。
