我正在考虑将我们的数据库转换为源代码控制。我找不到关于改进现有dbs与rh一起使用的最佳方法的任何信息。
我可以看到创建的表格应该只是将这些表格编入脚本并将它们添加到我们的数据库中,事情会从那里开始吗?或者我应该获得db的bak并使用restore标志运行rh?似乎应该有一些指导原则。
如果您有任何见解,请告诉我。
感谢
答案 0 :(得分:1)
你见过PowerUp吗? https://github.com/chucknorris/powerup
这是一个实用程序,用于将当前项目从数据库中提取为幂等RoundhousE格式。
就表而言,您可以单独编写脚本,然后将它们放入runAfterCreate表中。
维基上有一点指导 - https://github.com/chucknorris/roundhouse/wiki/RoundhousEModes
答案 1 :(得分:1)
从我收集的内容来看,这是预期的工作流程:
此备份文件是您的基准图像。将文件移动到具有固定位置的文件共享。已修复意味着当基线映像更新为较新版本时(通常在成功部署之后),完整路径不会更改。
\\BuildServer\Data\Backups\LegacyDb.bak
请注意,此时不应该编写“Onetime”数据库对象的脚本。
做一些涉及添加Onetime脚本或更改Anytime脚本的实际工作。也许添加一个新表并更改视图。相应地更新您的迁移脚本。
使用“RunRestore”模式将更改部署到开发数据库,并验证迁移脚本是否按预期工作。
在此模式下,在执行迁移脚本之前,现有数据库将替换为基线映像。恢复备份是必要的;否则,RH将不会执行先前执行的迁移脚本,因为开发数据库中的版本信息位于基线信息之前。您绝对希望能够对迁移脚本进行更改和测试更改,只要它们仍在开发中。
在此模式下,RH在执行迁移脚本之前不会还原任何备份。理论上,您的生产数据库和基线映像在整个sprint中保持不变,因此不需要恢复备份。更不用说它可能会摧毁数周/数月的数据。
如果这是第一次部署,RH将创建3个表,用于存储该数据库的版本信息。从现在开始,版本信息将包含在您的基线图像中。
此备份文件是下一个sprint的新基线图像。