优化

数据库版本迁移与Jenkins自动发布方案.md

@@ -182,7 +182,7 @@ baiyue-firstleg/
 
 ## 6. 自动编号和文件命名
 
-SQL 迁移使用每个 schema 内递增的整数序号，由创建工具生成。业务版本、Git commit 和 Jenkins 构建号只用于发布追踪，不参与 SQL 序号计算。无需开发人工决定“这次是 0.0.10 还是 0.0.11”。
+2026-09-22 确认：SQL 迁移保持 `V1、V2、V3、V4、V5……`，每个 schema 独立递增，由创建工具生成，不采用时间戳编号。序号随变更自然增长，不因位数增加而重置、归零或重新编号。生产发布版本、Git commit 和 Jenkins 构建号只用于发布追踪，不参与 SQL 序号计算。
 
 ```text
 migrations/cn/baiyue_order/V1__add_order_reference.sql
@@ -225,6 +225,24 @@ migrations/cn/baiyue_auth/V1__create_login_audit_table.sql
 - 同一库内按完整版本链推进，不按某个服务或某个文件跳过中间版本。该库随包包含的其他待执行变更必须一并评审；尚不具备发布条件时阻断本候选，不通过删文件、临时降低目标或开启乱序绕过。
 - 例如只发布 Auth，且与 Firstleg 无依赖，则只核验并迁移 Auth 的必要库。同一提交中 Firstleg 的待执行 SQL 不被带入；若 Auth 确实依赖 Firstleg 的新结构，则先补齐发布范围和测试证据再发布。
 
+### 6.3 功能分支与生产发布编号
+
+以下为确认的发布工作流；跨分支检查和发布编号自动分配尚待流水线实现，不代表当前工具已经提供这些门禁。
+
+| 记录 | 示例 | 增长规则 |
+|---|---|---|
+| 单库 SQL 迁移编号 | Auth 的 `V1`、`V2`；Order 的 `V1`、`V2` | 该库新增数据库逻辑变更时自动生成；普通提交、重复构建和重复部署不增加 |
+| 生产发布版本 | `release-1`、`release-2` | Jenkins 为新的生产发布候选自动分配，不要求开发手工维护版本文件；只有发布成功才更新当前生产版本 |
+
+生产发布版本与 SQL 编号不绑定。例如 `release-12` 可以对应 Auth `V3`、Order `V7`；纯代码发布仍有新发布版本，但数据库目标不变。发布编号须在受保护记录中唯一分配，失败编号不回收；同一制品重试沿用原发布编号，修改代码、SQL 或其他制品内容后分配新编号并重新验证。`release-13` 失败时保留失败记录，当前生产版本仍为最近成功版本；各库和服务的实际状态另行记录，不能据此假定没有发生部分更新。
+
+1. 功能分支从最新 `main` 创建，代码与 SQL 在同一分支维护；这里约定后续团队流程，不自动创建或切换本次工作区分支。
+2. 进入共享测试前，拉取并合并最新 `main`，检查同库重复编号和执行顺序。冲突只调整尚未冻结、未在保留历史环境执行的草稿；成功文件不改内容、不改编号，修复使用新增迁移。冻结失败候选只能按第 13.2.1 节处理。
+3. 两人可以并行开发；共享测试同一时间只验收一个待合并功能。前一功能测试通过、合并并完成发布或处理失败后，下一功能同步最新 `main` 再进入测试，避免未合并 SQL 污染其他功能的验证起点。
+4. 测试结果绑定提交和 SQL 哈希；合并前重新检查 `main` 是否变化，变化时同步并重新验证，不能仅凭“以前拉取过 main”放行。
+5. 合并后的 `main` 构建正式候选并再次自动验证；生产使用该正式候选原制品。功能分支测试证据不自动等同于合并后候选证据；已成功的 SQL 保持原编号及内容，由数据库历史决定跳过或执行。
+6. 发布记录绑定 `release-N`、`main` 的完整提交、镜像 digest、SQL 清单及各库版本，并保存成功发布的 Git 标签。`main` 表示已合并代码，实际生产版本以成功发布记录为准，不通过分支名称推断数据库历史。
+
 ## 7. 迁移类型
 
 ### 7.1 版本迁移
@@ -581,7 +599,7 @@ MySQL DDL 可能已隐式提交，不能假定整个文件自动回滚。按以
 - Jenkins 构建号。
 - Git commit 和镜像标签。
 - 发布身份、清单/SQL 包 SHA-256、各镜像 digest、审批及发布锁状态。
-- 候选制品身份、可选的业务发布标签，以及对应测试通过记录；不维护独立手工 SQL 发布版本。
+- 候选制品身份、生产发布版本 `release-N`、发布状态及对应测试通过记录；不维护独立手工 SQL 发布版本，编号规则见第 6.3 节。
 - 环境与区域。
 - schema 名称。
 - Flyway 镜像版本。
@@ -651,6 +669,7 @@ MySQL DDL 可能已隐式提交，不能假定整个文件自动回滚。按以
 - 实现 `plan/run` 及分阶段校验配置，在获授权的隔离数据库验证原始 SQL、首次执行、重复执行、结构断言与失败恢复；验证单服务范围隔离，并用应用预期结构及实际读写测试发现漏写迁移。
 - 单服务 Job 先支持构建与部署解耦；总控固定为“全部目标镜像就绪 -> SQL 阶段 -> 同批镜像部署”，此能力必须先于共享测试接入完成。
 - 全部独立部署入口纳入环境锁和候选资格校验，补齐归档保护、镜像保留、未决状态及撤销记录；禁止旧 Job 绕过新的 SQL 门禁。
+- 接入第 6.3 节的 main 同步检查、分支编号冲突检查和合并后候选验证；自动分配并保护 `release-N`，同一候选重试不换号，成功后更新生产版本和发布标签。
 - 对从未成功、未进入生产的失败候选验证第 13.2.1 节修订链；对已成功或生产尝试过的文件验证例外被拒绝。
 
 ### 阶段 D：共享测试完整演练