flydb-multi-environmentlisted

# Flydb 多数据库多环境自动化 在多个数据库家族（MySQL、达梦、Oracle…）× 多套环境下组织迁移：**一个数据库×环境一份 `flydb.conf`，密码外部注入，使用同一发行包和脚本产物**。Web 的配置登记、分组和环境标签不提供 CLI 配置继承或生产审批，不能替代流水线门禁。执行具体 CLI 命令、写迁移脚本分别由 `flydb-cli-release`、`flydb-migration-scripts` 覆盖。 ## 参考文档（按任务读取） | 文件 | 何时读取 | |---|---| | [`references/multi-environment.md`](references/multi-environment.md) | 完整组织模式：配置矩阵、密码分层、脚本仓库布局、流水线、baseline、驱动分发、能力边界 | 命令参数、配置键、错误码与 JSON/Plan 的参考在 `flydb-cli-release` 的 `references/` 目录；独立安装缺少该技能时优先读目标发行包的 `docs/`，缺失再定位源码文档，不猜测 schema。 ## 核心契约 1. **密码永不落盘到版本库/命令行**：本地明文仅限临时测试；CI 用 `FLYDB_PASSWORD` 或 `${env:VAR}`；生产用密码文件并收紧权限。自动化中不用 `-p/--password`。 2. **自动化永远显式传 `-c/--config`**：CI 与堡垒机工作目录不可控，隐式查找是配置漂移的主要来源；`flydb.locations` 一律写绝对路径。 3. **所有环境同一套命令序列**：`version → validate → --json --dry-run migrate →（生产审批门）→ migrate → info → validate`；每个环境独立生成计划和目标摘要，不能把测试库批准直接搬到生产。 4. **生产写入必须过审批门**：dry-run 清单与目标库摘要核对、获得明确授权后才 `migrate`；流水线中不自动 `repair`、不出现 `undo`/`clean`。 5. **迁移只有一个执行者**：CI 或应用启动（Spring Boot starter）二选一，避免时序依赖。 ## 工作流 ### 1. 盘点环境矩阵 与用户确认两个维度：**数据库家族**（mysql、dm、oracle…）× **环境**（uat、prod…），以及每格的连接信息来源、密码注入方式、执行者（CI 还是应用启动）。存量库要标注"已有手工历史，需 baseline"。 ### 2. 组织配置与脚本仓库 按 [`references/multi-environment.md`](references/multi-environment.md) 第 2、4 节落地： ```text deploy/ ├── flydb.mysql.uat.conf # 只放非敏感项；locations 用绝对路径 └── flydb.mysql.prod.conf migrations/ ├── mysql/ V1__init.sql V2__add_order.sql # 各家族版本流独立，天然隔离 └── dm/ V1__init.sql ``` - conf 进版本控制，密码位置全部外部化（第 3 节的分层表）。 - 新增脚本本身（命名/版本/纪律）交给 `