4. 版本发布流程：从开发分支到发布分支的完整流程
版本发布，说白了就是把代码从「开发环境」搬到「生产环境」的过程。很多团队觉得这步很简单——合并代码、打个标签、上线完事。但我见过太多因为发布流程不规范导致的线上事故了。
我个人习惯把发布流程拆成四个关键节点：代码冻结、回归测试、发布审批、正式发布。每个节点都有它的意义，缺一不可。
4.1 代码冻结：停止一切新功能开发
代码冻结，就是在一个特定时间点，禁止向发布分支提交任何新功能代码。嗯，这里要注意：冻结的不是所有代码，而是「新功能」代码。Bug修复和文档更新通常可以例外。
我在项目中遇到过这样的情况：某个团队为了赶一个功能，在冻结前5分钟提交了代码。结果这个功能引入了新的Bug，导致整个回归测试延期了两天。从那以后，我定了一条铁律——冻结时间点前1小时，停止所有合并操作。
代码冻结的典型规则：
- 冻结时间点：通常选择在发布前3-5天
- 允许提交：Bug修复、文档更新、配置修改
- 禁止提交：新功能、重构、依赖升级
- 例外处理：必须经过发布经理+技术负责人双重审批
实际操作中，我会在Git仓库里创建一个release/x.x.x分支，然后在这个分支上设置分支保护规则。只有特定角色（比如发布经理）才能合并代码到发布分支。
# 创建发布分支
git checkout -b release/2.1.0 develop
# 设置分支保护（GitLab示例）
# Settings -> Repository -> Protected Branches
# 选择 release/2.1.0
# 允许合并：Maintainers
# 允许推送：No one4.2 回归测试：别让旧功能出问题
代码冻结后，第一件事就是跑回归测试。为什么？因为新功能可能无意中破坏了旧功能。我曾经见过一个案例：一个看似无害的CSS修改，导致整个支付页面的布局错乱——测试了三天才发现。
回归测试我建议分三层：
| 测试层级 | 执行时机 | 覆盖范围 | 耗时 |
|---|---|---|---|
| 单元测试 | 每次提交 | 核心模块 | 5-10分钟 |
| 集成测试 | 每天一次 | 模块间交互 | 30-60分钟 |
| 端到端测试 | 代码冻结后 | 完整业务流程 | 2-4小时 |
你想想看，如果端到端测试跑一次要4小时，那每天只能跑两轮。所以我会在冻结后的第一天，优先跑端到端测试。发现问题立刻修，修完再跑一轮。这样三天下来，基本能跑6-8轮，覆盖率就上去了。
我的小技巧：在回归测试阶段，我会让QA团队把测试用例按优先级排序。P0用例（核心流程）必须全部通过，P1用例（重要功能）允许有少量失败但需要记录，P2用例（边缘场景）可以延后处理。这样即使时间紧张，也能保证核心功能不出问题。
4.3 发布审批：不是走形式
发布审批这个环节，很多团队把它当成「签字走人」的流程。但我认为，这是最后一道防线。
我曾经在一个项目中，因为发布审批太随意，导致一个未经验证的配置项直接上线，结果线上服务挂了半小时。从那以后，我要求发布审批必须包含以下内容：
- 测试报告：回归测试通过率、未通过用例的说明
- 变更清单：本次发布涉及的所有代码变更、配置变更
- 回滚方案：如果发布出问题，如何快速回滚
- 影响范围：本次发布会影响哪些模块、哪些用户
注意：发布审批不是一个人说了算。我建议至少需要三个人签字：
- 技术负责人：确认代码质量没问题
- 测试负责人：确认测试覆盖率达标
- 产品负责人：确认功能符合需求
缺少任何一个签字，都不能发布。
4.4 正式发布：从发布分支到生产环境
审批通过后，就是正式发布了。这里我推荐使用蓝绿部署或灰度发布策略，而不是直接全量上线。
我个人习惯的做法是：
# 1. 将发布分支合并到主分支
git checkout main
git merge --no-ff release/2.1.0
git tag -a v2.1.0 -m "Release version 2.1.0"
# 2. 部署到灰度环境（10%流量）
kubectl set image deployment/myapp myapp=myapp:2.1.0 --namespace=staging
# 3. 观察15分钟，确认无异常
# 4. 逐步增加流量：30% -> 50% -> 100%
# 5. 全量发布后，删除发布分支
git branch -d release/2.1.0为什么要灰度发布？说白了就是「小范围验证」。我曾经有一次全量发布，结果发现新版本的内存泄漏问题，导致所有节点OOM。如果是灰度发布，最多影响10%的用户，回滚也快。
4.5 发布后的收尾工作
发布完成不代表流程结束。我通常会做三件事：
- 监控告警：发布后24小时内，重点关注错误率、响应时间、资源使用率
- 问题跟踪：如果线上发现问题，立刻创建Bug，并评估是否需要热修复
- 发布总结：记录本次发布的问题、耗时、改进点，为下一次发布做准备
避坑指南：我曾经犯过一个错误——发布后没有及时清理发布分支。结果三个月后，有人误以为这个分支还在开发中，又往里面提交了代码。后来合并时产生了大量冲突。所以我的建议是：发布完成后，立刻删除发布分支。如果需要回溯，用Tag就够了。
好了，这就是我从开发分支到发布分支的完整流程。你可能会觉得步骤有点多，但每个步骤背后都有血的教训。记住一句话：发布流程越规范，线上事故越少。