假设有3个数据库：
- 生产环境
- 测试环境
- 开发环境
据我所知，测试环境需要与生产环境保持同步， 但是，
当我们在开发时，我们可以随意更改开发环境的数据库结构。 现在问题出现了。
为了在测试环境中进行测试，测试环境数据库结构需要根据开发环境所做的更改而改变。 但测试数据库需要与生产环境保持同步。
那么你们如何解决这个问题？
5个回答
10
你需要将所有更改写成SQL迁移脚本并按特定顺序运行在开发数据库中。除非它在脚本中，否则不要更改数据库结构。也不要更新、插入或删除任何行，除非它在脚本中。
最好有一种跟踪已针对任何版本的数据库运行哪些脚本的方法。
然后你可以按照以下方式更新stage。
最好有一种跟踪已针对任何版本的数据库运行哪些脚本的方法。
然后你可以按照以下方式更新stage。
- 转储生产数据库
- 使用生产转储填充stage数据库
- 在stage中运行迁移
- 检查迁移是否成功（单元测试，手动检查）
- 使用mysqldump命令转储prod数据库（因为它可能已更改），并在服务器上保留备份
- 在prod上运行迁移
- 测试迁移是否在prod上成功
- 喝啤酒（同时观察错误日志）
- RichH
5
在部署新变更之前，预发布环境需要与生产环境保持同步。
或者创建第四个环境——测试环境，用于验证新升级。我们称之为UAT/Test，通常是在预发布服务器上设置的第二个数据库。
确切的方法取决于您如何保持同步。您是否实际使用了复制？还是只是将生产环境备份/还原到预发布环境中？
- BradC
2
+1 显然，在部署更改时，生产环境和暂存环境需要一段时间不同步。当然，除非您同时将更改部署到两个环境中，但这完全违背了拥有暂存环境的目的。 - Tim Frey
目前还没有做出决定，但我正在考虑使用SQL Server日志传送来将暂存数据库与生产数据库同步。复制很可能不会被使用。 - dance2die
1
“Staging database need to be in sync with Production”这句话不是真的。
生产模式（“设计”）与暂存模式同步。暂存模式先行，生产模式随后。
有时候人们会将生产数据移动到暂存模式来进行测试，但这可能会很危险，具体取决于您所在的行业。
暂存模式是“纯净的”。
通过将真实数据放入纯净的暂存模式中，可以构建生产模式。
有些人会有两个数据库。
今天，#1是生产模式，#2是暂存模式。
明天我们计划对模式进行更改。我们将#2升级到新的设计。然后我们将数据从#1移动到#2。
然后，在我们完成数据移动之后，我们将应用程序软件切换为使用#2作为生产模式。
我们使用#2作为生产模式，直到下一次更改的时间到来。
- S.Lott
1
我们只使用暂存数据库来测试部署机制，它与生产环境相匹配。
我们在开发环境中创建更改，并定期将其部署到QA。一旦准备好进入生产环境，我们将所有更改聚合到一个发布包中。该发布包首先在暂存环境中进行测试，如果没有部署问题，则推送到生产环境。
- Michael L Perry
1
如果你有能力添加一个测试环境，那么你可能需要考虑一下。
否则，你基本上需要在开发环境中进行测试，直到你对发布的内容足够自信，可以在预备环境中进行模式更改。频繁备份并拥有良好的回滚程序，以便在将模式更改推送到预备环境时出现问题时，您可以随时回滚。
此外，一个比较数据库模式的好工具是SqlCompare。在推送模式更改之前，你应该始终使用这样的工具。
- Matt Schwartz
1
+1 for SqlCompare。我认为SQL Delta也是一个非常适合此类用途的优秀工具，应该得到一提。 - immutabl
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接