database - 生产环境上的 Laravel 4.x 迁移

Question

我是一位经验丰富的 DBA，但对 Laravel 的经验并不丰富。我的主要开发人员在 Laravel 方面经验丰富，但是倾向于掩盖数据库细节。目前的问题是我们一直在使用工匠的“迁移”和“播种机”。这一切在开发环境中都运行得相对良好(有一些小问题)。我们的产品现已推出初始版本并投入生产。 担忧:

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

2. 同样的担忧，我们的大多数播种程序都以“delete()”开始，基本上在运行之前删除表中的所有数据，我对在生产环境中使用文件运行 db:seed 毫无兴趣我们目前有。

3. 我在他使用的系统中没有看到任何区分生产环境和其他环境的内容，因此我们不会执行删除表等操作。

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

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

因此，将其归结为一个问题: 我是否缺少一些 re:mifrations(从 DBA 的角度来看如何在生产环境中使用迁移/播种器的文档)，或者我应该自己使用 .sql 文件管理架构？我在网上看到的大多数示例都掩盖了此类生产问题，我不愿意让我的数据面临风险。

Answer 1

...most of the migrations he's written have an up() and no down()...

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

Of similar concern, most of our seeders start with "delete()" basically deleting all data in the table prior to running, there's no way I'm interesting in running db:seed on production, with the files we currently have.

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

I see nothing in the system that he's using that differentiates between production and other environments so we don't do things like drop tables, etc.

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

if( App::environment() === 'dev' )
{
    $this->call('UserTableSeeder');
} 

...the apps DB user does not have permissions to create/drop tables, and can only insert and delete, preventing the accidental dropping of tables

您可以执行此操作，然后自己“创建”表，然后运行仅在表中插入/删除列的迁移。