database - 维护开发数据库的建议

Question

现在，开发人员都有自己的本地开发环境，其中包含生产数据库的快照——他们可以扭曲、搅动和破坏数据，而不会影响除他们自己以外的任何人。

这些快照开始变大，它们的数据导入开始需要将近一个小时。

在维护开发数据方面有什么更好的建议吗？开发数据可以被撕开以进行潜在的更改，然后如果更改想法不好，则需要将其重新组合在一起，等等。

Answer 1

我尝试使用以下方法：

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

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

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

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

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

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

我经常遇到对这种方法的抵制（“脚本太多”、“数据库太多”、“我不想使用版本控制，因为我的数据库建模工具不支持它”）。但是除了大量的手动工作之外，我真的没有看到其他选择。

Answer 2

通常，作为开发人员，您需要从开发数据库设置中获得一些东西。

您希望它易于使用 - 进行更改、保持这些更改版本并将它们应用到其他环境应该是简单的。

你想要有代表性的数据——并且让这些数据是可预测的。例如，如果您正在构建一个发票系统，您希望客户具有已知的信用额度，这样您就可以编写测试用例来跟踪他们在开具发票、付款等方面发生的情况。（集成测试，而不是单元测试） .

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

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

持续数据库集成为其中大部分提供了解决方案 - 并且还解决了“为开发环境设置数据库需要一个小时”的问题。

Answer 3

以我的经验，为每个环境拥有一个集中的 DB+数据：开发、测试+集成和生产一直是最好的方法。

• 开发：让开发人员为所欲为。如果需要类似生产的数据，请混淆/删除敏感数据。这个数据库越轻量级，越便于你移动、维护和备份。
• 测试：用它来模拟生产环境，让测试人员输入/检索所有需要的数据，但只能通过您的应用程序接口。此环境还允许您在将部署发送到生产之前对其进行测试，您不希望糟糕的数据库安装程序使生产应用程序处于不可用状态。如果需要，您可以使用生产数据输入此环境，但也可以混淆/删除敏感数据。您可以使用高容量在性能问题投入生产之前发现它们。
• 生产：不要管您的生产数据/环境，您不希望敏感数据落入坏人之手或数据库错误配置允许开发人员意外更改数据。

Answer 4

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

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

另一个想法是在开发机器上恢复一次，然后使用数据库快照快速恢复到干净状态。我发现一个特别有用。