生产环境中的 Laravel 4.x 迁移

Posted 2023-03-14

【中文标题】生产环境中的 Laravel 4.x 迁移

【英文标题】：Laravel 4.x migrations on production environment

【发布时间】：2014-07-27 23:48:51

【问题描述】：

我是一名经验丰富的 DBA，对 Laravel 的经验并不丰富。我的主要开发人员在 Laravel 方面经验丰富，但是，倾向于掩盖数据库细节。手头的问题是我们一直在使用工匠使用“迁移”和“播种者”。这在开发环境中运行得相对较好（有一些小问题）。我们的产品现已推出初始版本，现已投入生产。 关注点：

开发人员创建了许多迁移，我对这些迁移在生产环境中的陷阱知之甚少。例如：他编写的大多数迁移都有 up() 和没有 down()。由于系统很小，通常的做法是每次都重置整个数据库并重新加载所有迁移和播种器 - 显然我们不能在生产环境中这样做，所以我担心只在运行“laravel migrate”时系统充满了实时数据。

1234563我们目前有。

我在他使用的系统中看不到任何东西可以区分生产环境和其他环境，所以我们不做诸如删除表之类的事情。

我设置数据库的常规方法是拥有一个“受限”应用程序用户，即apps DB用户没有创建/删除表的权限，只能插入和删除，防止意外删除表。看来我必须拥有完整的数据库权限才能运行迁移和播种器，并且相同的数据库连接文件（和嵌入式用户名/密码）用于应用程序和模式生成，我宁愿拥有出于安全原因，一个 DBA 用户和一个 APP 用户。

我们的模式相对简单，只有大约 30 个表，我对它的管理非常自在，特别是因为 laravel 的模式构建器不支持许多 postgres 功能（json 数据类型、全文索引等），我们不断地执行 db::raw() 命令来创建索引、初始设置序列值等。

所以归结为一个问题： 我是否遗漏了一些 re:mifrations （从 DBA 的角度来看如何在生产环境中使用迁移/播种器的文档），还是我应该自己使用 .sql 文件管理架构？我在网上看到的大多数示例都掩盖了这样的生产问题，我不愿意让我的数据处于危险之中。

【参考方案1】：

...他写的大多数迁移都有 up() 而没有 down()...

这不是迁移的方式。他非常懒惰（或者只是很糟糕）。迁移应该是两种方式。这样，如果有人出错，您可以“回滚”。因此，无论您的up() 是什么，都应该始终有一个匹配的down()。

出于同样的担忧，我们的大多数播种机都以“delete()”开头 基本上在运行之前删除表中的所有数据，没有 我对使用文件在生产中运行 db:seed 很感兴趣的方式 我们目前有。

再一次 - 这不是正常的做法。你应该只是“播种”你所拥有的。

我在他使用的系统中看不到任何区别 在生产环境和其他环境之间，所以我们不做类似的事情 删除表等。

Laravel 有一个环境检测系统 - see here for more info。如果您想根据您的环境播种 - 您可以在 DatabaseSeeder.php 中执行类似的操作：

if( App::environment() === 'dev' )

    $this->call('UserTableSeeder');
 

...apps DB用户没有创建/删除表的权限，只能插入和删除，防止意外删除表

您可以这样做并自己“创建”表，然后运行仅在表中插入/删除列的迁移。

【讨论】：

我知道环境检测，但是，对于播种机而言，最好的方法是什么？播种器中的 if 语句，或以某种方式使用不同的播种器文件？