环境与分支映射
我们的流水线围绕两类环境搭建：
develop对应测试与联调环境，合并即自动部署。master搭配语义化版本标签，用于生产发布。
这样可以保证开发节奏稳定，同时让发布动作有明确的入口。
一次功能上线的节奏
- 从 develop 开分支：命名遵循
feat/日期-功能点的格式，例如feat/20251010-user-login。 - 本地提交：保持小步快跑，每次 commit 只包含一个意图。
- 推送与创建 PR：目标分支为
develop，PR 创建后自动触发 CI。
CI 阶段的检查项：
- 构建项目（Build）
- 代码质量 / Lint
- 单元测试
任何一步失败都会阻断合并，这样评审者能聚焦在业务逻辑上。
合并 develop 后的 CD
PR 通过评审并执行 “Rebase and merge” 后，自动化流程会：
- 构建镜像（例如
my-app:dev）。 - 推送至镜像仓库。
- 通过 SSH 或脚本部署到测试服务器。
几分钟后就能在联调环境验证实际效果。如果有多服务联动，可以在这里完成前后端互测。
面向生产的发布流程
当测试环境验收完毕，管理员会：
- 将
develop合并入master，并使用 “Squash and merge” 保持整洁历史。 - 在最新 commit 上创建语义化标签，比如
v1.2.0。 - 推送标签到远端，触发生产流水线。
流水线脚本会读取标签并执行：
git checkout master
git pull origin master
git tag -a v1.2.0 -m "Release v1.2.0"
git push origin v1.2.0
随后：
- 以标签号构建产物（Docker 镜像、压缩包等）。
- 将镜像推送到仓库，并部署到生产服务器。
- 部署完成后发送通知，提醒团队做回归验证。
上线前后的检查清单
- 配置文件是否已切换到生产参数。
- 数据库迁移脚本是否执行并校验成功。
- 监控与告警规则是否覆盖新功能。
- 发布后 30 分钟内安排排班确认关键链路。
总结
这套流程的关键点在于：分支与环境一一对应、CI 严格把关代码质量、生产发布必须绑定标签。保持节奏稳定后，团队能更大胆地做持续交付，而不是把风险堆到月底的大版本里。