如何实现一个良好的敏捷数据库流程，使其与代码库同步，特别是在持续集成方面？

Question

我正在处理的项目正在尝试找到一个解决方案，使数据库和代码具有敏捷性，并能够一起构建和部署。

由于该应用程序是代码加上数据库模式和数据库代码表的组合，除非您有随代码一起进行版本控制的数据库，否则您无法真正拥有完整的应用程序构建。

我们还没有能够想出在敏捷/Scrum环境中如何进行数据库开发以及与代码结合的良好敏捷方法。

以下是我的一些要求：

1. 我希望能够有一个与系统完整构建对应的svn修订号。
2. 我不想将二进制文件检入数据库的源代码控制。
3. 开发人员需要能够向持续集成服务器提交代码并一起构建整个系统和数据库。
4. 必须能够自动部署到不同的环境，而不需要重新构建除构建服务器上的原始构建之外的任何内容。

（更新） 我会在这里添加更多信息以进一步解释。

没有OR/M工具，因为它是一个具有大量代码的遗留项目。 我已经阅读了敏捷数据库设计信息，该过程孤立起来似乎有效，但我正在谈论将其与活动代码开发相结合。

以下是两种情况

1. 开发人员检入代码更改，需要进行数据库更改。开发人员应该能够同时检入数据库更改，以便自动构建不会失败。
2. 开发人员检入应该破坏代码的DB更改。自动构建需要运行并失败。

最大的问题是，这些事情如何同步。 “检入数据库更改”这样的事情是不存在的。现在应用DB更改是某个人必须手动执行的过程，而代码更改则不断进行。它们需要一起完成和检查，构建系统需要能够构建整个系统。

（更新2） 再添加一个：

您不能关闭生产环境，您必须修补它。重建整个生产数据库是不可接受的。

- John Sonmez

Answer 1

你需要一个构建过程来构建数据库架构并添加任何必要的引导数据。如果你正在使用支持 schema 生成的 O/R 工具，则大部分工作已经完成。无论是什么不是由工具生成的内容，都应该保留在脚本中。

对于持续集成，理想情况下，“构建”应该包括对数据库的完全重建和静态测试数据的重新加载。

我刚看到你没有 ORM 工具……这是我们以前公司用过的。

db/
db/Makefile (run `make` to rebuild db from scratch, `make clean` to close db)
db/01_type.sql
db/02_table.sql
db/03_function.sql
db/04_view.sql
db/05_index.sql
db/06_data.sql

请根据需要进行排版...每个*.sql脚本都将按顺序运行以生成结构。开发人员各自拥有数据库的本地副本，任何数据库更改都只是另一种代码更改，没有什么特别之处。

如果您正在开发已经具有构建过程（Java、C、C++）的项目，则这是司空见惯的。如果您使用脚本的方式没有任何构建过程，则需要额外的工作。

- Tom

---

我喜欢这个答案，这也是我的结论，但真正的问题是“如何”，这并不容易。这个想法很有道理，但是你如何重新生成整个生产数据库呢？你真的不能也不应该这样做。 - John Sonmez

你不需要在每次提交时重新生成生产数据库。你只需要重新生成数据库的结构，以及用于烟雾测试所需的最小数据集。即使对于大型数据库，这也不应该花费太长时间。 - Tom

此外，如果您的生产数据库中的数据量阻止您在几小时内从头开始重建，当真正的数据库最终崩溃时，您将会遇到生产问题。 - Tom

...而且...你在CI中所做的任何事情都不应该接近生产数据库。但是，这与你的代码相同。夜间构建不会在没有人工测试的情况下进入生产环境，数据库也是如此。 - Tom

Answer 2

“在数据库中进行“检查”是不存在的。”

实际上，我认为您可以检查数据库更改。诀窍是停止使用简单的 - 未版本化的 - 模式和表名称。

如果您将版本号附加到整个模式（或表）上，则可以轻松进行版本检查。

请注意，数据库版本没有花哨的主要-次要-发布版本。应用程序软件中的“主要”修订版通常反映了基本兼容性水平。该基本兼容性水平应定义为“使用相同的数据模型”。

因此，应用程序版本2.23和2.24使用数据库模式的版本2。

版本检入分为两部分。

1. 新表。例如，MyTable_8是给定表的第8个版本。

2. 迁移脚本。例如，MyTable_8包括一个将数据移动到MyTable_7至MyTable_8的脚本，提供默认值或所需内容。

有几种使用方法。

• 兼容升级。仅更改表以添加允许空值的列时，版本号保持不变。

• 不兼容升级。当添加非空列（需要初始值）或更改表或列的基本形状的数据类型时，您正在进行重大更改，并且需要迁移脚本。

请注意，在更改过程的末尾，旧数据保持不变，直到明确删除。您必须运行测试以确保一切正常工作。

您可能需要两部分删除 - 首先重命名，然后（一周后）最终删除。

- S.Lott

Answer 3

Ruby on Rails的migrations功能是专门为处理这种需求而开发的。如果您没有使用Rails进行应用程序开发，可以看看是否已将此概念移植到您选择的框架中，或者阅读相关资料并确定是否可以编写一些快速脚本来实现相同类型的功能。

- SFEley

Answer 4

确保您的O/R-Mapping工具能够根据默认配置构建必要的表格，并添加缺失的列。这应该涵盖90%的情况。

另外10%包括：

• 处理在插入数据后添加的列的缺失值
• 编写数据迁移脚本，以处理版本之间需要进行更基本更改的罕见情况

- saua

Answer 5

请查看DBDeploy开源项目。http://dbdeploy.com/

它允许您签入数据库更改脚本。然后，它将生成一个合并的更改脚本，包括所有未应用的更改。 该网站很好地描述了这个过程。

该项目基于Martin Fowler之前提到的技术文章。我曾经参与过Martin基于该文章的项目。DbDeploy是我们使用的过程的相当不错的实现。

- Mike Two