3

我正在考虑让我们的数据库进入源代码控制。我找不到任何关于改造现有数据库以与 rh 一起使用的最佳方法的信息。

我可以看到创建的表，我是否应该将它们编写脚本并将它们添加到我们的数据库中，然后事情将从那里开始？或者我应该得到一个 db 并使用 restore 标志运行 rh 吗？似乎应该有一些指导方针。

如果您有任何见解，请告诉我。

谢谢

4

2 回答 2

1

你看过PowerUp吗？https://github.com/chucknorris/powerup

这是一个将当前项目从数据库中提取为幂等 RoundhouseE 格式的实用程序。

至于表，您可以单独编写脚本，然后将它们放入 runAfterCreate 表中。

wiki 中有一些关于此的指导 - https://github.com/chucknorris/roundhouse/wiki/RoundhousEModes

于 2013-09-04T11:42:17.913 回答
1

据我所知，这是预期的工作流程：

  1. 创建现有数据库的完整备份。

此备份文件是您的基准映像。将文件移动到具有固定位置的文件共享。固定意味着当基线映像更新到较新版本时（通常在成功部署之后），完整路径不会改变。

\\BuildServer\Data\Backups\LegacyDb.bak
  1. 使用 SSMS 或 PoweruP 编写“随时”数据库对象（存储过程、函数、视图和索引）脚本，每个文件一个对象。将脚本移动到名为“sprocs”、“functions”、“views”和“indexes”的目录中。

请注意，此时您不应该编写“一次性”数据库对象的脚本。

  1. 做一些涉及添加 Onetime 脚本或更改 Anytime 脚本的实际工作。也许添加一个新表并更改视图。相应地更新您的迁移脚本。

  2. 使用“RunRestore”模式将您的更改部署到开发数据库并验证您的迁移脚本是否按预期工作。

在这种模式下，在执行迁移脚本之前，现有数据库会被替换为基线图像。恢复备份是必要的；否则，RH 不会执行之前执行的迁移脚本，因为开发数据库中的版本信息在基线信息之前。只要迁移脚本仍在开发中，您绝对希望能够对迁移脚本进行更改和测试更改。

  1. 当您有足够的信心时，使用“正常”模式将您的更改部署到生产数据库。

在这种模式下，RH 在执行迁移脚本之前不会恢复任何备份。理论上，您的生产数据库和基线映像在整个 sprint 中保持不变，因此不需要恢复备份。更不用说它可能会破坏数周/数月的数据。

如果这是第一次部署，RH 将创建 3 个表，用于存储该数据库的版本信息。从现在开始，版本信息将包含在您的基线图像中。

  1. 创建数据库备份。

此备份文件是下一个 sprint 的新基准映像。

于 2015-06-25T14:19:06.293 回答