多人开发的时候,migration 不会有问题吗?

每个人都在本地用migration建个表,然后本地执行,然后commit,push。
假设所有人操作的都是不同的表,migration代码间没有冲突,那么更新了其他人的migration代码后(可能有的在自己的migration时间前面,也有可能在后面),本地再执行migrate会怎么样?

《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
《G01 Go 实战入门》
从零开始带你一步步开发一个 Go 博客项目,让你在最短的时间内学会使用 Go 进行编码。项目结构很大程度上参考了 Laravel。
讨论数量: 23

:wink:改迁移的打死

4年前 评论

那么更新了其他人的 migration 代码后

Migration 按理说不应该修改。需要改表应当新增 Migration。

4年前 评论
Summer

不应该被工具限制住,如果你与他人刚刚好是修改同一个数据库表里的同一个字段,这已经就是冲突了,这时候应该灵活地采用「人为干涉」。

有点像 Git 里的冲突。

4年前 评论

每个migration执行迁移后都会在数据库的migrations表中流行一条记录的,框架识别是否执行迁移应该是根据这个表判断的!

4年前 评论

那么更新了其他人的 migration 代码后

Migration 按理说不应该修改。需要改表应当新增 Migration。

4年前 评论

:wink:改迁移的打死

4年前 评论

@Wi1dcard 我的意思不是修改,就是每人各自建一个自己的migration文件,假设内容也不冲突,是建的不同的表。但是在同一次提交,并auto merge了。里面的顺序有先有后。开发的时候自己的那个migration肯定run过了,提交并merge后,把别人的migration更新到本地了,有的在自己前面,有的在自己后面,这种情况下,本地会不会乱掉?还能执行migration不?

4年前 评论

@Kamicloud @Wi1dcard 老哥们看下我楼上的补充,这种情况有没有问题?

4年前 评论

时间前后不影响迁移的

4年前 评论

理论上有些情况会有冲突的,比如A和B新增了名称相同的一张表或者字段或者其他不能相同的东西,还有比如A删除了一张表而B修改了这张表,然而这只是理论情况,实际上基本不会遇到,除非沟通需求的时候靠眼神儿交流的

4年前 评论

我们在迁移文件里会增加一个判断,如果表或字段存在就跳过
检查数据表 / 字段是否存在
可以使用 hasTable 和 hasColumn 方法来检查数据表或字段是否存在:

if (Schema::hasTable('users')) {
    //
    Schema::create('users', function (Blueprint $table) {
                $table->increments('id');
                ...
    }
}

if (Schema::hasColumn('users', 'email')) {
    //
}

这样能够避免一部分冲突

4年前 评论
Summer

不应该被工具限制住,如果你与他人刚刚好是修改同一个数据库表里的同一个字段,这已经就是冲突了,这时候应该灵活地采用「人为干涉」。

有点像 Git 里的冲突。

4年前 评论

@kiyoma 每次migrate时,都会按顺序执行所有未执行的migration,每次rollback,都会按照batch_id倒序回滚migration。所以你可以认为是乱的,因为执行顺序不是按时间戳,而是谁先提交谁先执行。这个乱只会在你们的migration有冲突时才有体现,正常修改不同数据谁先谁后无所谓。

你们可以强制提交人要从最新代码开分支合并,并自己测试好迁移是否冲突。

4年前 评论

@Summer 如果不是呢,不是修改同一张表同一个字段。只是不同的人在开发不同的子功能,每个人在自己负责的逻辑部分造新表,并不时对表进行修修补补,并没有操作别人的migration文件。然后提交并合并。
由于开发的时候肯定在本地跑过migration了,而别人的代码合并进来,就会有大量没执行过的migration和自己写的已执行过的migration穿插混合在一起——这种情况,算是冲突吗?还是说完全不用担心,laravel能自动处理好这些?

4年前 评论

@kiyoma 你可以像站长说的那样,按照Git的方式理解冲突。你们没有提交过重叠(如都添加了相同的列)或互不兼容(如一个人改了索引名,另一个人按旧索引名删除)的迁移,或是对执行顺序(如B基于A的分支开发,A增加了列,B又修改了列,必须A先提交)有强制要求,就不算有冲突。在没有冲突的情况下,laravel会自动处理,处理方式如我上次回答的一样。

4年前 评论
hainuo

其实项目中 的migration建议由专人负责制 从根本上杜绝随便建,随便改的习惯。
在我们的项目中数据库的任何操作都是有专人来负责的 需要执行migration的时候也是要有专人执行命令,然后个人copy 数据库到本地 或者直接使用公共库

4年前 评论

@hainuo 专人负责不如做下code review,招人过去只让写业务代码也挺无聊的

4年前 评论
hainuo

@hausir 我说的也是我们公司目前情况。你说的在很多产品型团队是合适的。但是,就我所在的环境来说, code review 耗时不少啊,感觉除非团队已经成熟,否则费力不讨好。目前外包类公司人员变动频繁的,基本不适用,即便是变动不频繁,处在生存线上的团队,也不应该花时间在在这上面,这个应该是要负债的。

4年前 评论

@hainuo 我的意思是说可以只针对数据库迁移做code review 这样感觉比专人负责要好 首先对于负责的人来说只需要看和测试运行一下 不需要写了 对于团队来说也不需要有涉及到数据库迁移的都跟专人商量减少沟通成本 另外两个人过一遍总比一个人过要好

4年前 评论
hainuo 4年前
xiaopi

多人开发,涉及到相同模块的时候,喊一嗓子啊

4年前 评论
hausir 4年前
奕鹏 4年前

这个 我想刚开始是 一起讨论后 由一个人负责搭建一个架子

4年前 评论

这样使用迁移是不是就很容易避免冲突?
1.数据库有多少表就对应多少迁移文件
2.新建表增加迁移文件,删除表时删除对应的迁移文件
3.需要修改表字段的时候直接修改对应的迁移文件,例如修改字段名: 修改前:$table->string("username");
修改后:$table->string("name");

如果多人修改、添加同一个字段,git合并时会出现冲突,可以及时发现解决问题,而不是等到执行migrate出错时,再回头去解决迁移失败的问题。
合并完成以后,
开发环境:执行 php artisan migrate:fresh --seed 重建整个数据库的表结构并填充数据。
生产环境:先备份,然后使用工具对比新旧结构生成sql并部署。

1年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!