您如何控制和管理数据库的多个分支？

Question

警告:长期问题.

[题]

如果策略是每个数据库都有一个分支,如下面的问题所述,其中脚本受版本控制.

在尝试整合到较少的分支时,如何管理数据迁移问题？
这只是您在数据迁移过程中产生的成本吗？

实际上,必须在迁移时创建转换脚本.

有没有更好的办法？
我们可以同时解决这两个问题吗？
什么是最佳做法？

[背景]

在我的工作场所,我们有一个有3个分支的产品.主线有"最新和最大"的变化,没有必要准备发布.

• 版本B(名称已更改以保护有罪)
• 版本A(名称已更改以保护有罪)
• 主线

由于这些分支,实际上有3个版本的数据库.代码版本控制相当容易,但数据库版本控制似乎很难.

阅读您是否对数据库项使用源代码管理？ 似乎最好的方法是导出每个对象/表的所有创建脚本.注意:根据文章,您可以在一个大脚本或多个脚本或混合脚本中管理它.

我同意这一点,并询问为什么没有这样做.

目前,DBA拒绝将脚本分支到分支.除了懒惰作为借口之外,原因是节省了数据迁移的时间.实际上,所有版本都强制维护数据库更改.

所有脚本都受版本控制,仅在主线中维护.版本A和版本B有自己的特殊文件,说明哪些更改脚本在其各自的分支上运行.当存在更改脚本时会出现问题,例如应用于版本A但版本B仅需要部分更改.开发人员可以通知DBA更新文件,该文件指示要为每个分支应用哪些补丁.对于需要进行过多手动干预的更改脚本,需要手动应用部分更改脚本.

要在版本A上更新数据库,所有补丁都将使用版本A提取,以便应用文件补丁.

[SCENARIO]

• 存在上述3个版本.
• 版本A发生数据库更改.
• 分支合并,其中代码从版本B合并到A,以便可以删除版本B.
• 数据库也需要发生同样的情况.

希望这是有道理的.

Answer 1

请参阅Eric Sink 的《源代码控制指南》中的第 8 章。这是了解源代码控制的详细信息的重要资源。