1
fx 2014-07-11 16:32:47 +08:00
参考 rails db migration,
就算不用rails,也可以单独使用 rails的migration模块 |
2
hging 2014-07-11 16:41:59 +08:00
架设一个公用的数据库服务器=。= 我太蛋疼了。
|
3
datou552211 2014-07-11 16:48:16 +08:00
@fx 他说的应该是数据库数据吧,数据库结构的话不就是一个sql文件的事吗
|
4
JoshuaJin 2014-07-11 16:49:53 +08:00
一般用migration工具来保证数据库的完整性,然后根据不同的构建工具来配合。
如果是java,maven的话用flyway。 |
5
jinnietsai 2014-07-11 17:39:15 +08:00
我觉得一个比较简单但是挺low的办法就是如果是mysql的话可以参考用mysqldump,然后交给对方去还原。
|
6
abelyao 2014-07-11 18:57:01 +08:00
弄一个可远程连接的数据库,大家连同一个,就 mysql 或者 sql server 来说都可以,网上也有相应的服务,价格很低,其它数据库没接触过。
|
7
dorentus 2014-07-11 20:37:06 +08:00
不要共享数据库,共享数据库结构就可以了。
共享数据库结构的话,用 migration 也罢,用 SQL 也罢,自己写个机制也罢,都不会很麻烦。 |
8
jamesxu 2014-07-11 21:07:04 +08:00
用 docker 吧
|
9
sunus 2014-07-11 21:16:17 +08:00
liquibase
|
10
ericls 2014-07-11 22:07:13 +08:00 via Android
用sqlite3直接一起commit push
|
11
gracece 2014-07-11 22:10:39 +08:00
我比较low地用了远程数据库,感觉还不错,安全性还需考虑。
|
12
Livid MOD 我们的做法是:
* 团队里的成员都用 phpMyAdmin 管理各自开发环境里的数据库 * 每次 phpMyAdmin 里确定要改任何东西的话(大的更改之前肯定是有会议记录的),把实际执行了的那句 SQL 发到内部的协作系统里(比如论坛,Basecamp 或者 Quip 之类的系统),并且加上一些文字说明这个修改的目的是什么 * git commit 时也同时要提到需要进行 SQL 操作 * git repo 包括一个当前最新的原始数据库的 SQL 定义 同时因为代码全程都用 Sentry 监控,所以如果 git pull 之后发现是因为表结构不一致导致的问题的话,马上就收到邮件了。 |
13
orcx 2014-07-11 23:14:34 +08:00
更改的sql也可以通过类似update.sql放到git里管理
|
14
akfish 2014-07-11 23:20:35 +08:00 1
基本原则就是库数据不能进入版本控制,只共享结构,也就是说明性文档、数据库生成代码等等。
中心化的一个共享测试数据库在有的阶段并不适用,团队成员调试bug时的的误操作可能会污染这个数据库,影响测试的正确性和可重复性。所以必须要有分布式的方案,每个成员跑隔离的数据库。 我曾经在一个项目里用过脚本自动按规则生成随机测试数据,在测试的setup里创建填充数据库,teardown的时候销毁,这样需要共享的数据量最小,能保证可重复性,而且随机数据的测试覆盖率也要高得多。 |
15
huoxiaochai 2014-07-12 09:25:02 +08:00
数据库表 table_name_user 用于个人开发 table_name_demo 用于大家协作, table_name_online 线上版本
|
18
suprod 2014-07-13 10:11:03 +08:00 via iPhone
SQLite 可以吗
|
19
laoisaudi 2014-09-02 18:14:45 +08:00
用过Python和node.js来写过两个相似的web站点项目,第一个数据库(mysql)是通过使用mysqldump的方法导出来push到repo上,第二个是数据库(mongodb)通过放在一个共同的服务器上,这样修改代码就不需要考虑数据的重复复制
|