在提出版本化数据库工作是一个必要规则这一观点之后，Scott Allen 又详述了一个做好版本化数据库的方法，他给出了一个易于理解、实践性很强的方法，通过创建基线、使用变更脚本的方法来管理数据库的修订、控制程序化数据库对象（如视图、存储过程、函数和触发器），并充分利用分支和合并。
Allen 在发布了关系型数据库开发的三个原则的经验总结文章之后，就开始写后续的系列文章了。这三个原则如下：
一、不要在共享数据库服务器上进行开发工作 > 就像软件开发中其它所谓便捷的方法一样，共享数据库的使用也是一个泥潭，它正等着冻结一个项目呢。开发人员相互覆盖彼此所做的修改，我在服务器上所做的改变让你的开发机器上的代码中断运行，这些都让远程开发速度很慢而且非常困难。避免使用共享数据库，也就免避了因使用它造成的极度时间浪费和因之而生的 Bug。
二 、 仅保留一份权威的 Schema 生成源 > 每一个人都必须知道该从哪里获得正式的 Schema，并且可以用它轻松地重新创建一个新的数据库。当我走到电脑前，可以从源码库中获得最新的版本，构建后就可以通过最简单的工具创建数据库（在更多的场景中，构建的过程甚至可以在数据库不存在时自己创建一个，所以这个构建过程应该是一步到位方式的）。
三、对你的数据库进行版本管理 > 这样做的原因之一就是要将变化由开发传递到测试，最终在一种可控制的、一致的环境下生产。其二就是可以重建任何时间点上的数据库，如果你正在将软件交付给客户的话，这一点就尤为重要。如果有人在你提交的应用版本 build 20070612 中发现了 bug，你就必须能重建当时那个版本的状况——包括数据和其它所需。
Allen 说明了版本化数据库的目的就是为了能保证所做的改变能保持一致性、可控性、可测试性和可重现性。许多推广者都同意这一点，并认为实现这个目标对任何一个敏捷团队的效率都很重要。
在列出了版本化数据库的重要性后，Allen 又相继发布了４个贴子来描述他推荐的实现方法。
其中，第一篇贴子描述了 Allen 宣称的版本化数据库的起点——创建一个数据库 Schema 基线。从本质上来讲，这个基线是一个脚本，或者是一连串脚本，它包含所有可以从零开始生成应用数据库的 SQL 命令。它包括创建所有数据库所有对象（表、约束、函数、视图、索引等）的 SQL 命令、表查询及操作命令和插入应用所需初始数据的命令。Allen 建议，一旦它完成创建并且验证无误，应立刻“将它提交到源码控制库”，此时“你可以认为已将数据库基线化了”。
对于如何创建这个基线，Allen 建议使用那些能从现有数据库中导出脚本的工具（与手工编写他们的过程相反）。作为参考，他还描述了他是如何结构化那些生成的脚本文件的：
Allen 建议并强调，基线中需要一个表用来记录任何有关数据库结构的改变，在他后面的三个贴子中，他详细描述了该如何处理这些变化。
首先，Allen 讨论了变更脚本——一种管理除视图、存储过程、函数以外的数据库对象的机制。这种方法要求任何一个改变（或一组相关的改变）必须有一个新生成的脚本文件可通过“增量”更新的方式来代表，这与Ruby Migration很相似。换句话说，当团队发现数据库需要做改变时，他们创建一个新的脚本来将数据库修改到想要的样子，通过测试后提交到源码控制库中。一旦发布后，这个脚本就永远不要再修改。
Allen 这么做使视图、存储过程和函数的更新方式与其它数据库对象完全相反，每个对象都有一个“创建命令”文件，然后通过更新这一个文件来更新这些对象，对于为什么他喜欢这样做，他解释到：
Allen 着重强调了利用自动化工具更好地实施上述策略的重要性：
对于遵循这些策略的好处，尤其是使用自动化工具，Allen 给出了一些示例：
Allen 在这一系列文章的最后，还提及他是如何处理分支与合并的，而这是所有应用在版本服务器上建立它的第一个版本后都要面对的现实问题。Allen 建议为发布而分支，这也是他偏好的分支策略，同时解释了他为什么会为每个新的发布版本重创数据库基线。他通过一个示例来描述了这个问题，并添加了这样一个场景：在较早版本中发现了缺陷，就必须对已分支的版本进行相应的数据构结构变更。在这个分支版本中，创建新的脚本来处理变更是没有问题的，问题是，如何将这个变更也应用到当前的主线版本中：
想获得更多信息和相关内容，请查看Scott Ambler 的《take on agile_blank"> Continuous Integration And Version Control for>
