本节书摘来自异步社区出版社《测试驱动数据库开发》一书中的第2章，第2.4节，作者：测试驱动数据库开发，更多章节内容可以访问云栖社区“异步社区”公众号查看。
2.4 增量构建
测试驱动数据库开发
那么，该如何与上述机制进行交互呢？最好的方式应该是把数据库的每一次变更当做一个单独的版本用文档记录下来，并找到一个好方式（如版本号）来将这些变更进行排序。只要数据库能够标识已经发生了哪些变更，就能构建一个通用的机制来按正确的顺序实施正确的变更。
2.4.1 用文档记录每一次数据库的变更
开始的时候，只编写涉及一个变更的脚本。只要该脚本没有在重要的数据库上运行，就可以根据开发人员的意图，或者根据需求的变化，来随意地修改这个脚本。此时，该脚本其实是在不久的将来要做的事情的计划。
然而，当将变更提交（commit）到数据库之后，就再也不要修改上述脚本。这是变更被提交到生产环境的过渡，意味着该脚本不再是将来要发生的变更的蓝图，取而代之的是，该脚本变成了记录过去发生的事情的文档。所以从本质上讲，这个文档现在变成了历史记录。
当变更已经被提交并变成历史记录后，就可以为下一次变更创建一个新的文档。开发人员可以持续地修改这份文档，直到该文档以一种不可逆转的方式被提交到数据库为止，然后停止修改该文档，并创建另一份文档。
通过文档记录每一步骤执行的顺序也很重要。这既可以像为每份文档分配一个版本号这样的简单（如版本1是用于创建一个初始化的数据库，版本2是用于添加一些结构，等等），也可以像指出这一个过渡要先于另一个过渡这样的复杂。另外，也可能记录与上述情况完全不同的内容，比如像给一个已经提交的版本添加日期戳，来标识本次变更首次提交到生产环境的确切时间。
2.4.2 标识当前版本
数据库构建机制必须能够标识哪些变更已经施加到某个给定的数据库实例之上。这一点很重要，因为这样就可以避免将过去已经实施的变更再次施加到数据库上。要做到这一点其实比较容易，通常在数据库中创建一个表来标识在什么时间对数据库施加了哪个版本的脚本。
2.4.3 根据需要依次实施变更
在上述条件都具备后，就能构建一个机制，用来在正确的时间实施正确的变更。在只存在版本的线性增长这种最简单的情况下，即每个版本仅有一个前驱（predecessor）版本和最多一个后继版本，开发人员可以用非常低廉的成本来编写该机制。在以下章节内容中将介绍一些能够展示该机制如何工作的伪代码。在本书的配套代码中有一个实现该机制的代码示例，将其移植到你的系统平台上应该不会太困难。请访问http://maxthe3rd.com/test-driven-database-development/code.aspx来下载代码。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。
