更新条令迁移表的最佳方式

Question

概述

我有一个使用条令迁移的应用程序。该应用程序是一个软件代码库，用于管理多个企业，这些企业都在自己独特的环境中使用相同的代码实例。即，除了配置之外，每个代码库是相同的。

我们犯的错误

开发团队犯的一个错误是将核心迁移包含在客户文件夹中。即，对于每个新的应用程序，我们都必须放入迁移文件或运行迁移：diff才能启动，我觉得这效率不高，可能会导致混乱。

我更喜欢将核心迁移作为核心代码的一部分，因为它很少在客户端应用程序端进行更改和自定义迁移。

我想做什么

1. 我想将所有核心结构迁移移到我们的代码文件中
2. 我想进行一次自定义迁移，将自定义数据放入客户端迁移文件夹中

问题

我面临的问题主要是如何在不破坏现有客户端应用程序数据库的情况下重新组织迁移。

我想到了两个解决方案：

解决方案1：

1. 添加空白迁移作为我想要的新迁移的占位符
2. 将它们提交给回购并部署到我们的环境中
3. 他们将被运行，什么都不会改变，migraitons表将把他们存储为已执行
4. 接下来，将空白迁移更新为我想要的实际代码，并清空所有其他迁移文件。将其提交给环境
5. 最后，删除不需要的迁移文件，删除不想要的数据库迁移记录

溶液2

1. 将数据库中的迁移位置更改为新位置
2. 删除所有迁移文件，并为我想要的新文件添加空白迁移
3. 将其提交给repo，允许在新表中运行并记录迁移
4. 添加迁移代码

现在，所有新应用程序都将具有更新的迁移文件，而旧应用程序将具有新的迁移文件。。。

问题：

我是在重新发明轮子吗？有没有一个标准来说明如何做到这一点，因为我确信我不是第一个遇到这个问题的人？

Answer 1

因此，对于那些发现自己处于类似位置，需要整理混乱的条令迁移的人来说，这应该是一个简单的模式。

在我们的开发环境中，我们使用持续集成/git/kubernetes等，以下过程与我们的环境配合良好。

步骤：

1. 更新迁移表名称，这可以很容易地在配置中完成

'table_storage' => [
'table_name' => 'migration_version',
'version_column_name' => 'version_timestamp',
],

2. 接下来，删除旧的迁移(删除文件(并运行迁移：diff以生成一个新的迁移，该迁移将是您所有更改的组合。

3. 现在注释掉新文件中的代码，使其本质上是一个空的迁移文件。

4. 在本地，删除旧的迁移表并运行构建过程，该过程将把新的迁移添加到新表中。

5. 承诺开发/上演/直播等，并重复该过程。

6. 现在，所有环境中的数据库都有更新的迁移文件。您现在可以取消注释提交文件时不会执行的代码，因为它存在于迁移表中。

• 希望这能帮助到别人