不仅仅只控制代码，也要控制数据

作者：查德·拉·瓦因

源代码控制和持续集成，是管理应用程序构建过程和部署过程的优秀工具。数据方案（schema）和数据内容通常会随着源代码的变化而变化，它们也是这一过程的重要组成部分，因此也需要对之进行类似的控制。如果构建和部署过程的详细步骤列表中包含要进行数据更新的操作时，一定要明白这点。你一定碰到过这样的过程列表，看起来大致像是下面这样的：

1. 创建脚本列表，这些脚本要按照一定次序运行。
2. 把这些脚本通过E-mail发送给数据库管理员。
3. 数据库管理员把这个脚本复制到某个地方，通过定时任务调度（cron job）来执行。
4. 检查脚本的执行日志，祈祷所有的脚本都能够运行成功。要是必须重新运行这些脚本，真不知道到底会生什么事情。
5. 运行校验脚本，进行数据抽样检查。
6. 对应用程序进行回归测试（regression test），看哪些地方被破坏了。
7. 编写脚本，补上丢失的数据，修补被破坏的地方。
8. 重复上面的操作。

好吧，说得也许有点夸张，但也应该八九不离十。为了能够成功完成数据库迁移，很多项目都要经历这种像玩杂技一样的工作流程。

由于某种原因，在架构规划过程中，数据迁移部分似手很容易被架构师忽略。最终，数据迁移往往只是作为一项事后补救措施，而且整个过程由手工操作完成。相当脆弱（brittle）。

这样一种复杂的网状工作过程，失败的几率很同。更糟糕的是，由于数据方案和数据内容变化造成的错误，并非总能被单元测试捕获到，因些通过夜间构建报告（nightly build report）也无法发现错误状况。这种错误经常会在迁移己经完成后的构建中，突然冒出头来，闹得人心惶惶，十分烦人。要消除这些数据库问题，只有依靠单调乏味的手工回退。而且验证解决方法的有效性，往往也会变得更加困难。完全自动化构建过程（a completely automated build process）的价值，在于它能将数据库恢复到某个己知状态下。如果一个问题很明显是因为数据库迁移所引起，使用这种方法修复，完全自动化构建的价值就体现得更加明显。删除数据库并迅速将数据库重新恢复到与应用程序的某个特定版本相兼容的状态，如果不能做到这点，也同样无法做到可在不同代码版本间迅速地切换。

数据库的变化不应该影响构建活动的连续性。要把数据库也作一个构建单元包含在内，做到一次性构建整个应用程序。对数据方案和数据内容的管理，应当尽早无缝集成到自动化的构建和测试过程中，还必须提供回退功能；这样做能获得巨大的收益。做得好，可以省去在夜间构建失败后顶着巨大压力去解决问题的痛苦时光。最起码，如果继续开发需要重构数据访问层，大家丝毫也不必担心。