维护dev数据库的建议

Question

现在，开发人员都拥有他们的本地开发环境，其中包含生产数据库的快照 - 他们可以扭曲，流失和打败数据，而不会影响任何人，除了他们自己。

这些快照开始变大，并且它们的数据导入开始接近一个小时。

维护开发数据有哪些更好的建议？开发数据可能会因潜在的变化而被拆开，如果变更想法不好，则需要将其重新组合在一起等。

Answer 1

我尝试使用以下方法：

开发人员维护一个基于版本控制的基线脚本，并从头开始设置数据库架构。它创建模式，就像它在生产数据库中一样。

他们还维护一个“脚本”来设置测试数据。这个“脚本”实际上使用了生产类，有时候使用了一点点DSL。为了合理快速，脚本只生成最小的testdata。我建议将其作为done的定义的一部分，为任何新的功能构建创建一些testdate。

开发人员可以在其数据库（或数据库架构）上随意运行这些脚本。第一个脚本也用作运行自动数据库测试的基础。

开发人员完成的任何工作的结果都是迁移脚本。即可以应用于生产数据库以使其达到新的所需状态的脚本，包括对数据的更新。

可以在生产数据库的快照上测试这些迁移。生产数据库的快照也用于运行负载和性能测试。

仅针对快照我使用特定于数据库的工具。其他一切都是用主编程语言编写的（对我来说是java），所以开发人员觉得使用它很舒服。

我经常遇到对此问题的抵制（“太多脚本”，“太多数据库”，“我不想使用版本控制，因为我的数据库建模工具不支持它”）。但是从大量的手工作品来看，我并没有真正看到另一种选择。

Answer 2

通常，作为开发人员，您需要设置开发数据库中的一些内容。

您希望它易于使用 - 应该直接进行更改，保留这些更改的版本，并将其应用于其他环境。

您希望拥有代表性数据 - 并且可以预测该数据。例如，如果您正在构建一个发票系统，那么您希望客户具有已知的信用额度，以便您可以编写测试用例来跟踪发生发票，付款等情况。（集成测试，而不是单元测试） 。

您希望能够查询代表性数据卷，以便在开发和生产中出现性能问题。

您永远不希望能够影响“真实”数据 - 例如，您希望电子邮件地址和名称是匿名的，您希望重置密码。

Continuous Database Integration为大多数问题提供了解决方案 - 并且还解决了“为开发环境设置数据库需要一个小时”的问题。

Answer 3

根据我的经验，为每个环境提供集中式DB +数据：开发，测试+集成和生产是最好的方法。

• 开发：让开发人员随心所欲地做任何事情。如果需要类似生产数据，则模糊/删除敏感数据。这个数据库越轻，移动，维护和备份就越好。
• 测试：使用它来模拟生产环境并让它 测试人员输入/检索所需的所有数据，但只能通过您的 应用程序接口此环境还允许您测试部署 在将它们发送到生产环境之前，您不需要糟糕的数据库安装程序 使生产应用程序处于不可用状态。如果需要，你 可以使用生产数据输入此环境但是混淆/删除 敏感数据。在生产之前，您可以使用高容量来发现性能问题。
• 制作：保持您的生产数据/环境不受影响 希望敏感数据最终落入坏人之手或数据库错误配置中，以允许开发人员意外更改数据。

Answer 4

我处于同样的境地。我有想法将存档数据移动到只读文件组，这样我只需要备份和恢复一次。非归档数据会小得多，可以更频繁地复制到备份存储和开发机器。

当然，只有在可以将大部分数据库大小分割为只读文件组时才有效。

另一个想法是在dev计算机上恢复一次并使用数据库快照快速恢复到干净状态。我发现一个特别有用。