代码版本管控及迭代交付方案

一、背景与现状分析

当前存在的问题

• 服务多、版本无规划：各微服务数量庞大，缺乏统一的版本控制和功能归属规划。

• 分支管理混乱：频繁在 dev 分支上直接修改并发布，未形成稳定分支策略。

• 流程不规范：产品经理与开发之间缺乏清晰的发版流程约定，影响交付节奏。

• 功能修改重复性高：同一个功能需在多个项目或分支重复开发。

• 版本无法追踪：当前各环境运行版本不清晰，发布后无法快速定位问题。

• 缺乏变更记录与归档机制：历史版本不可追溯，问题排查困难。

• 责任不清，协作困难：缺少明确的职责划分与交付边界定义。

​适用范围​：所有微服务及项目
​核心原则​： "确定迭代、分支隔离、版本归档、功能可溯"

二、方案设计目标

• 建立统一分支管理规范

• 推行双周迭代制

• 明确产品经理的责任与流程参与

• 实施版本号规范与归档机制

• 制定跨项目功能修改协同机制

• 推行版本运行情况登记

• 完善培训与流程落地机制

三、当前问题诊断（需改进项）

四、核心管控机制

（1）分支策略（强制遵守）

​规则​：

• master：生产对应分支，​只读​（仅CI/CD可修改）

• release/*：每迭代生成独立分支​（如 release/20250731.0）

• dev：日常开发分支，​每天自动Rebase​

• feature/*：功能分支，​迭代开始后2天内创建​

• hotfix/*：紧急修复分支，​需技术负责人审批​

✋ ​禁止行为​：直接向dev/master提交代码、跨迭代共享分支

项目上BUG提过来要分析是紧急性和重要性，需要PM进行规划，紧急的hotfix，不紧急的做迭代规划。不能无条件进行发版

（2）分支规划

（3）版本号规范

[迭代截止日期].[序列号]-[环境]
​示例​：20250731.0-release

• ​迭代截止日期​：YYYYMMDD格式（如2025-07-31）

• ​序列号​：同一迭代多次发布时递增（.0, .1, .2...）

• ​环境标识​：
  dev - 开发环境 | test - 测试环境 | release - 生产环境

（4）迭代流程（14天周期）

• 每 2 周 为一个迭代周期（可根据实际调整）

• 每个迭代开始前必须：

  • 由产品经理提交《迭代功能清单》

  • 评审功能点、确定排期

• 迭代结束时必须：

  • 开发合并代码至 release

  • 由产品经理验收功能点

  • 归档版本，生成《版本归档文档》

三、关键执行规范

产品经理（PM）职责

1. ​迭代规划会​（每双周一上午）：

2. 提交《迭代功能清单》模板：

   # [产品线名称]迭代功能清单
   **迭代版本**：20250815.0  
   **周期**：2025-08-01 至 2025-08-15  
   **产品负责人**：张三
   
   | 微服务   | 功能ID | 功能描述       | 验收标准                | 涉及分支          | 跨项目影响 |
   |----------|--------|----------------|-------------------------|-------------------|------------|
   | SMT服务 | PAY-21 | 退料流程优化   | 处理时间≤3秒            | feature/pay-refund | QMS服务   |
   | Kernel服务 | USR-45 | 登录安全加固   | 通过OWASP A3测试       | feature/login-sec  | 无         |
   | LES服务 | PRO-87 | 类目管理重构   | 兼容历史API             | feature/category   | QMS服务   |
   
   ## 关键变更说明
   1. PAY-21：需QMS服务同步更新退料状态接口
   2. PRO-87：废弃/v1/category接口，启用/v2/category

3. ​版本追踪​：

   • 维护《服务版本对照表》（记录各环境运行版本）

     # 生产环境版本快照
     **记录日期**：2025-08-15  
     **负责人**：李四
     
     | 环境      | SMT服务版本      | Kernel服务版本      | LES服务版本      | 部署时间   |
     |-----------|-------------------|-------------------|--------------------|------------|
     | 生产      | 20250731.0-release| 20250715.2-release| 20250801.1-release | 2025-07-31 |
     | 预发布    | 20250815.0-rc     | 20250815.0-rc     | 20250815.0-rc      | 2025-08-14 |
     | 测试      | 20250815.0-test   | 20250815.0-test   | 20250815.0-test    | 2025-08-07 |

4. ​变更通知​：

   • 涉及多服务的修改，需在规划会上明确依赖关系

5. 验收测试通过的功能并签署确认

开发组长职责

1. ​分支监管​：

   • 审核所有非dev分支的创建申请

   • 每日检查分支合并合规性

2. ​代码合并管控​：

   # 正确操作示例：
   git checkout -b feature/payment_opt   # 创建功能分支
   git push origin feature/payment_opt   # 开发提交
   git request-pull dev feature/payment_opt  # 生成合并请求

3. ​版本归档​（迭代结束次日）：

   • 给release分支打Tag：
     git tag -a 20250731.0-release -m "订单模块升级"

   • 合并master后锁定分支：
     git branch --move release/20250731.0 archived/20250731.0

四、支撑工具链

注：环境检查工具将拒绝以下操作：

• 向dev分支合并未关联issue的代码

• release分支包含未通过测试的提交

五、实施路线图

1. ​第1周​：

   • 所有微服务建立master保护分支

   • 废弃现有dev分支（新建受控dev分支）

2. ​第2周​：

   • 实施首次规划会，生成首个release分支

   • 部署自动化检查工具

3. ​第3-4周​：

   • 完成首轮迭代闭环，进行版本归档

   • 优化流程卡点（收集团队反馈）

4. 建立落地监督小组，由研发负责人牵头

5. 各项目必须指定一位版本管理员

6. 持续每月评估执行情况，问题反馈迭代改进

考核要求：PM能独立填写功能清单，开发组长可演示正确合并流程

​此方案生效后，将实现​：
✅ 所有变更可追溯至具体迭代
✅ 紧急修复可在2小时内完成生产部署
✅ 版本回滚时间从小时级降至分钟级

建议首次迭代选择2-3个核心服务试点，逐步推广至全系统。关键成功因素在于第一轮迭代的严格执行，需技术负责人每日检查分支状态。