实现敏捷数据库流程的好方法是什么,它与代码库同步,特别是在持续集成方面？

Question

我正在研究的项目是试图提出一个解决方案,让数据库和代码保持敏捷,并能够一起构建和部署.

由于应用程序是代码加上数据库模式和数据库代码表的组合,因此除非您拥有与代码一起版本化的数据库,否则您无法真正拥有应用程序的完整版本.

我们还没有能够在敏捷/ scrum环境中提供一个良好的敏捷方法来进行数据库开发以及代码.

以下是我的一些要求:

1. 我希望能够拥有一个与系统完整版本相对应的svn版本#.
2. 我不想将二进制文件签入到数据库的源代码控制中.
3. 开发人员需要能够将代码提交到持续集成服务器,并将整个系统和数据库组合在一起.
4. 必须能够自动部署到不同的环境,而不进行构建服务器上的原始构建之外的重建.

(更新)我将在这里添加更多信息以进一步解释.

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

这是两个场景

1. 开发人员检查代码更改,这需要更改数据库.开发人员应该能够同时检入数据库更改,以便自动构建不会失败.

2. 开发人员检查数据库更改,这应该会破坏代码.自动构建需要运行和失败.

最大的问题是,这些事情是如何同步的.没有"检查数据库更改"这样的事情.现在,数据库更改的应用是一个人必须要做的手动过程,同时不断进行代码更改.它们需要一起制作并一起检查,构建系统需要能够构建整个系统.

(更新2)还有一个补充:

你不能降低生产,你必须修补它.重建整个生产数据库是不可接受的.

Answer 1

您需要一个构建过程来构造数据库模式并添加任何必要的引导数据。如果您使用支持模式生成的 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++）的项目，那么这是第二天性。如果您使用脚本的方式根本没有构建过程，那么这将是一些额外的工作。