文档版本:v1.0 最后更新:2026-04-03 16:20:00
本文档用于约定:
当前原则只有一条:
建议至少分 2 套数据库环境:
dev:开发 / 联调 / demo / workbenchprod:正式生产如果条件允许,推荐分 3 套:
devstagingprod其中:
dev 用于日常开发和联调staging 用于上线前预演prod 只承载正式业务数据当前仓库已经采用 migration 驱动结构演进,目录位于:
当前已存在的迁移文件包括:
0001_init.sql0002_launch.sql0003_home.sql0004_results.sql0005_config_pipeline.sql0006_resource_objects.sql0007_variant_minimal.sql0008_production_skeleton.sql0009_event_ops_phase2.sql因此正式上线时,数据库结构应以这些 migration 为准,而不是以当前测试库的现状为准。
第一次正式上线建议按以下顺序执行:
至少应与开发环境分离以下配置:
DATABASE_URL开发环境中的 .env 不能直接视为生产配置。
参考文件:
第一次上线时,建议只导入最小必要数据,例如:
不建议把开发联调用的 demo 数据直接原样导入生产。
每次后续正式上线建议固定为以下顺序:
关键接口最少应验证:
launchsession start / finishresult / history禁止做法:
所有数据库结构变化都应:
不应依赖口头约定或临时 SQL。
开发 demo 数据、联调活动、手工实验数据,应停留在:
devstaging不要直接进入 prod。
每次上线都应能回答两件事:
建议发布节奏为:
dev 验证staging 演练prod对当前仓库,正式上线前建议至少确认:
DATABASE_URL 已切到生产库当前项目的正式上线方式应固定为:
不要把开发测试数据库直接视为生产数据库。