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

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

《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
讨论数量: 16

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

1周前

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

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

1周前

:wink:改迁移的打死

1周前

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

1周前

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

1周前

时间前后不影响迁移的

1周前

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

1周前
aen233

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

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

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

这样能够避免一部分冲突

1周前
Summer

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

有点像 Git 里的冲突。

1周前

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

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

1周前

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

1周前

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

1周前
hainuo

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

1周前

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

1周前
hainuo

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

2天前

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

2天前

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!

社区文档:

将托管在 packagist.org 和 github.com 的扩展包使用国内 CDN 加速
GitHub Laravel 扩展包 TOP 250
速查表方便快速查询框架功能,支持手机访问,支持中英文版本
Laravel 中文文档,由社区用户翻译和维护,将会保持一直更新
此文档的目的,就是为了提高技术团队的凝聚力、一致性和生产效率。
开发环境的部署,开发者工具的选择,适用于 Mac 和 Windows。
浓缩过后的精华
Laravel Nova 后台管理面板文档的中文翻译
Lumen 中文文档,由社区用户翻译和维护,将会保持一直更新
Laravel 下知名扩展包 Dingo API 的中文文档,Laravel API 开发必知必会