我正在研究的项目是试图提出一个解决方案，让数据库和代码保持敏捷，并能够一起构建和部署。
由于应用程序是代码加上数据库模式和数据库代码表的组合，除非您拥有与代码一起版本化的数据库，否则您无法真正拥有应用程序的完整版本。
我们还没有能够在敏捷/ scrum环境中提供一个良好的敏捷方法来执行数据库开发以及代码。
以下是我的一些要求：
（更新） 我将在这里添加更多信息以进一步解释。
没有OR / M工具，因为它是一个包含大量代码的遗留项目。 我已经阅读了敏捷数据库设计信息，这个过程似乎有效，但我说的是将它与活动代码开发相结合。
这是两个方案的
开发人员检查代码更改，这需要更改数据库。开发人员应该能够同时检入数据库更改，以便自动构建不会失败。
开发人员检查数据库更改，这应该会破坏代码。自动构建需要运行并失败。
最大的问题是，这些事情是如何同步的。没有“检查数据库更改”这样的事情。现在，数据库更改的应用是一个人必须要做的手动过程，同时不断进行代码更改。它们需要一起制作并一起检查，构建系统需要能够构建整个系统。
（更新2） 还有一个补充：
你不能降低生产，你必须修补它。重建整个生产数据库是不可接受的。
答案 0 :(得分：3)
您需要一个构建数据库模式的构建过程，并添加任何必要的引导数据。如果您正在使用支持模式生成的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 ++）的项目，那么这是第二天性。如果您使用脚本的方式根本没有构建过程，那么这将是一项额外的工作。
答案 1 :(得分：2)
“没有”检查数据库更改“。”
实际上，我认为您可以检查数据库更改。诀窍是停止使用简单 - 无版本 - 架构和表名。
如果您有一个版本号作为整体（或表格）附加到架构，那么您可以轻松地签入版本。
请注意，数据库版本没有花哨的主要次要版本。应用软件中的“主要”修订通常反映了基本的兼容性。该基本兼容级别应定义为“使用相同的数据模型”。
因此，应用版本2.23和2.24使用数据库架构的版本2.
版本签到有两个部分。
新表。例如，MyTable_8是给定表的第8版。
迁移脚本。例如，MyTable_8包含一个MyTable_7到MyTable_8脚本，用于移动数据，提供默认值或任何必需的内容。
有几种使用方式。
兼容升级。仅仅更改表以添加允许空值的列时，版本号保持不变。
升级不兼容。添加非空列（需要初始值）或更改表的基本形状或列的数据类型时，您将进行大的更改，并且您有一个迁移脚本。
请注意，旧数据保持不变，直到在更改过程结束时明确删除。你必须运行测试以确保一切正常。
你可能有两部分掉线 - 首先重命名，然后（一周之后）终于掉线。
答案 2 :(得分：1)
确保您的O / R-Mapping工具能够使用其拥有的默认配置构建必要的表，并添加缺少的列。这应该涵盖90％的案例。
其他10％是
答案 3 :(得分：1)
请参阅DBDeploy开源项目。 http://dbdeploy.com/
它允许您签入数据库更改脚本。然后，它将生成一个合并的更改脚本，其中包括尚未应用的所有更改。 该网站很好地描述了这个过程。
该项目基于前面提到的Martin Fowler文章中的技术。我参与了马丁基于该项目的项目。 DbDeploy是我们使用的流程的一个很好的实现。
答案 4 :(得分：1)
开发Ruby on Rails的迁移工具是为了满足这种需求。如果您没有将Rails用于您的应用程序，您可能会看到是否已将此相同概念移植到您选择的框架中，或者阅读它并确定是否可以编写一些实现相同功能的快速脚本。