我即将开始为已经投入生产的数据库构建现有应用程序的API。功能将在未来慢慢移植到API,应用程序将变得更加“以API为中心”。
主要出发点之一是采用迁移和构建过程。我对保留现有模式的迁移的最佳方法有所保留,而不会在执行时中断生产。
由于我们希望快速将功能移植到API,我们理想地希望在构建过程中重新创建当前架构并获得一些核心单元测试 - 而不是仅仅为将来的更改创建迁移
这是我不确定最佳起点的地方。
这样的任务的最佳方法是什么?
if ( App::environment() !== 'production' )
确保它不在生产环境中执行?是否可能有其他方法或某些简单的错误? :)
答案 0 :(得分:3)
我很久以前创建了一个工具,它将生成当前数据库模式的所有迁移。它还将新创建的迁移添加到迁移表,因为表已存在。你可以在这里得到它:https://github.com/Xethron/migrations-generator
其次,我在DatabaseSeeder中使用以下代码行,但您可以将它添加到您希望在生产中禁用的任何函数中:
if (App::environment() === 'production') {
exit('Don\'t be stupid, this is a production server!!!');
}
如果你通过抛出错误或像我上面那样停止执行,那应该不是问题。如果不这样做,Laravel会认为更改已成功发生并从迁移表中删除,并在运行迁移时导致错误。唯一的例外是如果你同时排除上下代码(但我不明白你为什么要这样做)
希望这有帮助。
答案 1 :(得分:1)
我根本不建议在生产环境中运行迁移,但是如果你必须首先制作数据库的备份副本,并在本地创建数据库的副本并在那里进行迁移然后进行测试以确保一切正常。
由于使用artisan从CLI运行迁移,您可以传递环境以及要运行迁移的数据库:
artisan migrate --database =" connectionName" --env ="本地"
除了我上面提到的用于制作之外,在特定环境中运行迁移没有问题。
请记住将步骤1中的所有现有架构布局(不包括扩展名的迁移文件名,例如2014_03_25_143340_AddCountriesTable)添加到数据库中的迁移表,否则在步骤2中运行该命令将导致有关表的错误已存在。
希望这有帮助。