关键在于一体化触发与产物协同：统一以main或release分支合并为入口，前端dist产物注入后端jar或构建成统一Docker镜像，同步部署、环境变量注入、冒烟测试及带commit标记的可追溯回滚。
要实现前后端项目的自动化协同发布，关键不是分别跑两套流水线，而是让它们在同一个触发事件下联动执行、共享版本、共用制品、统一部署节奏。核心在于“一体化触发”和“产物协同”，而不是简单地把前端构建脚本和后端构建脚本拼在一起。
统一触发与分支策略
前后端代码即使分仓管理，也要约定统一的发布入口：比如只对 main 或 release/* 分支的合并（Merge Request）触发全链路流水线。避免前端改了接口、后端没同步，或反之——靠人工对齐版本极易出错。
- GitLab 中可在两个仓库都配置相同 webhook 触发条件（如 Target Branch =
main+ MR approved） - 推荐使用
git submodule或monorepo结构，让前后端代码在同一个 commit hash 下被拉取，天然保证版本一致 - 若必须分仓，流水线中需显式指定前后端对应 commit SHA（例如通过 MR 描述、自定义变量或 Git tag 关联）
构建阶段解耦但产物归一
前端和后端构建逻辑不同，但最终要打包成可部署的统一单元。常见做法是：
- 前端构建生成
dist/目录，不直接上传服务器，而是作为构建产物传给后端任务（如通过 GitLab 的artifacts或挂载共享目录） - 后端（如 Spring Boot）在构建时，将前端静态资源复制进
src/main/resources/static或通过 Maven 插件注入 jar 包内 - 或者更现代的做法：用 Docker 构建多阶段镜像——前端用 Nginx 基础镜像托管静态文件，后端用 JRE 镜像提供 API，最终打包为一个含反向代理的统一镜像
部署环节强绑定环境与配置
前后端不能各自往不同路径部署，而应视为一个服务单元。部署动作必须同步、原子化：
- 使用同一份部署脚本（如 Ansible Playbook 或 K8s Helm Chart），同时更新前端资源和后端服务
- 环境变量（API 地址、Feature Flag）应由 CI 流水线根据目标环境（test/staging/prod）注入，而非写死在代码里
- 上线前自动执行轻量级冒烟测试：例如调用后端健康检查接口 + 访问前端首页并校验状态码/关键元素存在
可观测与回滚闭环
协同发布的价值不仅在于“快”，更在于“稳”。每次发布必须附带可追溯、可逆转的能力：
- 流水线自动打 Tag（如
v1.2.0-fe-ba），其中fe和ba分别标记前后端 commit short SHA - 部署成功后，自动上报版本信息到配置中心或 CMDB，并触发企业微信/钉钉通知，含链接直达本次构建日志与制品地址
- 回滚操作应一键触发：K8s 场景下 rollback deployment revision；传统服务器场景下，切换软链接指向上一版
/opt/app/v1.1.0目录即可
