这是一个创建于 89 天前的主题，其中的信息可能已经有所发展或是发生改变。
场景描述
软件项目开发过程中：有测试环境、生产环境
- 大家经常在测试环境中，数据库里添加表、添加字段、添加了初始化的数据了
- 上线生产环境时，总是会发现：某个表的字段没有添加，初始化的一个配置表数据没初始化上。
请问大家有什么好的方式：能通知或者记录或者其他形式，来避免这种配置数据呀、表结构呀遗漏的问题呢？
目前通过 Gitlab 实现代码统一管理； 通过 Navicat 中数据库结构的比较，避免表结构的遗漏； 但是仍有一些初始化的数据，在上线后会遗漏。
45 条回复 • 2024-08-22 10:44:09 +08:00
 |
1
t298 89 天前  2
Flyway?
|
 |
2
jmllx1963 89 天前
|
 |
3
forvvvv123 89 天前 3
把大家测试环境 DB 的建表和修改表权限全回收了，然后做个网页工具管理表结构，测试环境生产环境也只有这个工具有权限改，所有变动只能 网页工具=>改测试环境=>改生产环境； 这样就行了；
然后定个规定，私自搭建测试环境 db 罚钱； |
 |
4
linjian 89 天前
liquibase
|
 |
5
InkStone 89 天前
赞同三楼，这种一致性需要流程保障
|
 |
6
28Sv0ngQfIE7Yloe 89 天前
alter table 以及 create table 的操作都要放到 migrate 脚本里，并且准备好执行失败的回滚脚本
|
 |
7
pangdundun996 89 天前
ddl 也作为交付物放到 git 中管理起来，标准化需求上线 checklist
|
 |
8
Mystery0 89 天前
上生产谁的 sql 出问题就扣钱，执行一段时间之后，开发人员自己会想办法做一个流程来避免问题
|
 |
9
fds 89 天前
我见过的不少 ORM 都有带版本管理的，会自动应用代码库里的 schema 变更。这些 migration 也可以手动升降。比如：
https://docs.edgedb.com/get-started/migrations https://hexdocs.pm/ecto_sql/Ecto.Migration.html |
 |
10
killva4624 89 天前
SQL 文件也要版本化管理，V1.0 ～ V1.5 顺序执行，数据库已执行的 SQL 要有对应版本号信息（你甚至可以直接建一个表记录当前版本号）。
基于这点的原则下去管理，GiT 也好、开源工具也好。 |
 |
11
nuistzhou 89 天前 via iPhone
dbt ？
|
 |
12
NoobNoob030 89 天前
datagrip 表结构对比工具
|
 |
13
XiLingHost 89 天前
不要让开发操作数据库，要改就在本地 dev 环境改，测试环境和生产环境一律使用 migration sql 脚本和 init 脚本跑数据库迁移/升级和初始化，这些脚本随自动构建产生的制品提供，比如在 docker 镜像里打包并在服务启动时执行，必须确保幂等性
|
 |
14
securityCoding 89 天前
ddl 也得放到发布单 checklist 里面接受 review
|
 |
15
leyfung 89 天前
navicat 同步数据，表结构比较
|
 |
16
jaylee4869 89 天前
flyway 原生 SQL 可以直接基于版本维护变更，同时支持多数语言 SDK
|
 |
17
yiqiao 89 天前
migration 迁移文件呀。别在测试服手动添加表和表字段。
|
 |
18
twofox 89 天前
liquibase 和 Flyway 不就是做这个事情的吗
|
 |
19
Rennen 89 天前
在某司实习用的确实是三楼的方法
另外还有发布时 checklist |
 |
20
sampeng 89 天前
现在几乎所有语言都有 migration 框架。。。
之前招了一个哥们死活不同意用，嫌弃麻烦和脱裤子放屁，那就让他浪。三天两头上线忘记字段，然后。。然后就老实了 |
 |
21
wu67 89 天前 1
不要让开发直接改数据库. 让他写好 sql / script 后 找 运维/数据库管理员 执行操作.
|
 |
22
sunhelter 89 天前
CodeFirst 迁移结构至数据库，这不是 ORM 必须标配的功能嘛
|
 |
23
dododada 89 天前
3 楼就是标准方法，账号密码统一收口，所有操作界面化，日志化，可审计可追溯可回滚
|
 |
24
RandomJoke 89 天前
既然你们已经通过 gitlab 管理了，说明你们可能没有专门的 DBA ，那不如直接 flyway 么，代码记录脚本，数据库记录执行情况
|
 |
25
BiChengfei 89 天前
再给开发搭建一个开发环境啊。在测试改表，是因为本地项目只有接口，不好测试验证，测试环境有页面，点点点比较舒服
说扣钱的我服了 |
 |
26
ilaipi 89 天前
这种情况就得老老实实写 migration
|
 |
27
Breacher 89 天前 via iPhone
这个过程叫做 DB migration, 有很多工具可以做这个事情，比如 go-migrate, Flyway 等。将这件事情集成到 CD 就不会出现忘记加表或者字段了。
|
 |
28
liuhuansir 89 天前
难道不是开发环境、测试环境、预发布环境、生产环境，四套么？开发环境，开发人员随便折腾，其他三个环境，开发没权限
|
 |
29
luozic 89 天前
三楼这种看起来不方便，但是你项目多，or 维护久了 就知道笨方法比瞎鸡儿整还节约时间，避免莫名其妙的问题
|
|
30
luozic 89 天前
毕竟三楼这种时间是可以放入计划的，但是瞎整，查莫名其妙问题的时候，哪时间就完全拼人品
|
 |
31
6167 89 天前
python, flask, flask-migrate 非常好用。可以同步表结构，upgrade 或 downgrade
顺便点赞 20 楼，我隔壁也是这个死性子 @sampeng |
 |
32
8355 89 天前
预发布环境充分测试。。。
这个问题跟通过什么方式能保证生产环境无 bug 一样，是人的问题。 |
 |
33
chendl111 89 天前
不保证环境一致，有关键字段添加则通知生产方
|
 |
35
Vtwoguest 89 天前 via iPhone
>数据库里添加表、添加字段、添加了初始化的数据
不好意思 大家加了表或者字段没有任何设计资料吗？ Sql 设计书、性能测试书、表说明书、DDL 等等 |
 |
36
MangoFlavor 89 天前
这是人的问题，
|
 |
37
coderzhangsan 89 天前
楼主反馈的问题是部署流程管理的问题，流程执行和把关不严；有运维或 dba 的情况下，开发人员不要操作数据库，数据库不是代码，不适合做 CI/CD ，由专业人员操作比较合适，如果没有，那就是你们技术主管的职责，毕竟部署环节缺失字段，顶多是短时间影响业务，而数据库误操作那可能就要祭天了。
|
 |
38
mark2025 89 天前
所有建表 DDL 纳入 git 版本管理
任何表结构变动必须在版本管理中有提交记录 |
 |
39
dddd1919 89 天前
关键词：DDL 、DML
搜索技术栈的具体实现，分别用来管理数据库结构变更和关键数据变更，保证各环境的数据一致 除了工具，还要有完善的运作机制，保障公用的测试以及生产库变更全部走 DDL 或 DML |
 |
40
lasuar 89 天前
测试环境 没有必要和生产环境严格一致。测试环境存有单独用于测试的表或字段，上线的表结构改动添加到代码中就行了，比如建个目录 ddl_history 保存 20240808.sql ，如果连这个都忘记写，那就是人的问题了。
|
 |
41
litchinn 89 天前
如果是大型项目应该收回开发对测试环境的操作权限，交给测试或运维，数据库改动提供脚本给测试或运维执行。
小项目可以用一些自动化工具，java 系有 liquibase ，flyway 等。 但是这些也是逃不开自己写脚本的。 养成习惯，不要在 navicat 上直接改动数据库，改动时不要直接 Ctrl+s ，而且将那个 sql 预览复制出来执行 |
 |
42
qiyilai 88 天前
尝试过好多，最后只能用严格执行的规章流程来控制，全部修改都得有 sql 语句汇总到版本管理员
|
 |
43
runliuv 88 天前
SQL 脚本 + SVN/GIT 。
|
 |
44
yinshaojun96 88 天前
@linjian 我们拿这个做测试生产数据同步，但是这玩意还能同步构建表么？
|
|
45
linjian 79 天前
@yinshaojun96 可以建表 https://github.com/liquibase/liquibase 可以看下这个
|
Select Language