数据库版本控制完全指南

　　在这个充斥着大数据与商业智能的新代时，唯一不变的技术就是变化，尤其是在数据库方面。出于数据统计、继续增加的对服务的需求，以及规定制度等方面的原因，几乎每天都有业务方面的变更需求，这些都会对数据库产生变更需求。当数据库变更发生时，能否从自动化中获得更大的敏捷性，以较少的资源实现较多的功能，正是那些具有高度竞争力的世界级企业在芸芸众生中脱颖而出的关键因素。

　　如果你的竞争对手能够更快地、并且交付质量更好的特性，那么 你必然会失去市场份额。敏捷开发方法的出现正是为了在应对不断变化的需求的情况下快速地发展，在有限的资源下也能够确保理想的质量。

　　重量级发布的方式已经过时了，为了每次更新或发布要等上足足六个月，这种方式无异于自掘坟墓。敏捷开发方法减少了每次发布的范围，换取的是更快地完成每个变更，并且将每个变更的影响降至最低。对于技术公司与IT部门来说，必须以敏捷性来保证对不断变化的业务需求的支持。

　　为了在敏捷的Sprint发布中有效地应用DevOps，你需要实现部署与流程自动化，自动构建内部的开发与QA环境，以及生产环境。否则的话，你只能选择手动实现部署与发布的每个步骤与流程，这就很可能产生人为的错误，而且也无法频繁地重复这一过程。

　　实现自动化依赖于版本控制系统，它能够管理所有等待构建并部署到下一个环境的软件资产。

　　构建流程的第一个步骤是清理工作空间，并从版本控制库中换取相应的文件。这一重要的步骤避免了流程外的变更。如果开发者直接将变更保存到构建服务器的工作空间，而不是将变更签入版本控制库中，那么这种变更仍然有可能产生。这个例子听起来似乎有些可笑，因为开发者都明白，如果不把变更签入到版本控制库中，这些变更就会丢失，因为技术手段保证了流程的正确性。这一步骤同时也避免了将尚未完成的变更包含至构建过程中，只有通过正确的签入流程提交至版本控制库中的变更才会加入构建过程。版本控制库在这里成为了唯一的信赖源。

数据库是关键的部件

　　如今多数的IT应用程序都包括数量众多的部件，使用了多种不同的技术：移动、ASP、PHP、应用程序服务器、Citrix及数据库等等。为了让应用程序正确运行，必须让这些组件相互配合。下面举个例子，如果在某张表中加入了一个新的列，或是在某个存储过程中加入了一个新的参数，那么为了让功能正常运行，其它所有的应用程序组件也必须与结构的变化进行同步。一旦同步过程出错，应用程序在调用存储过程时使用了错误的参数，或者是在插入数据时遗漏了新的列，应用程序就会出错。

　　数据库组件的独特性将它与其它组件区别开来：

• 数据库不仅仅只是SQL脚本，还包括了表结构、在存储过程中用数据库语言编写的代码、在引用表或配置表中所存放的内容，以及对象之间的依赖等等。
• 数据库是集中式的资源，多个开发者可以在同样的对象上进行工作，因此必须对他们的工作进行同步，以避免代码相互覆盖。
• 数据库变更的部署不像拷贝与替换旧版本的二进制文件那么简单，在将数据库从版本A转换至版本B的过程中，需要在保留业务数据的同时转换为新的结构。
• 数据库代码直接存在于数据库中，并且可以在任何环境中进行直接修改。这一点就与其它的组件不同，它们都是在构建服务器中的某个干净的工作空间中进行编译的。

必须满足的需求

　　在管理数据库变更时，需要克服一系列的困难，你必须做到以下几点：

1. 确保所有的数据库代码都被涵盖（结构、代码、引用内容和授权等等）
2. 确保以版本控制库作为唯一的信任源
3. 确保被执行的部署脚本在运行时能够正确判断环境状态
4. 确保部署脚本能够正确处理与合并冲突
5. 只为相关的变更生成部署脚本
6. 确保部署脚本了解数据库的依赖项

　　对于在开发阶段，以及内部部署（开发环境与QA环境）或部署到生产服务器时的数据库变更管理，有四种通用的管理方式。

1. 建立开发阶段生成的SQL变更脚本
2. 建立一个变更日志的跟踪系统
3. 建立简单的比较与同步机制
4. 建立一个数据库执行变更管理解决方案

建立开发阶段生成的SQL变更脚本

　　管理数据库变更的最基本方式，就是将所有变更命令保存在一个或一系列脚本中，并且在基于文件的版本控制系统中对它们进行管理。以此保证在一个单一的存储库中保存所有的应用程序组件资产。对于开发者来说，将数据库变更进行签入可以使用的功能类似于他们签入.NET或Java的变更时的功能，例如将变更与变更原因（变更请求、缺陷编号、用户故事等等）相关联。对于当前流行的各种基于文件的版本控制方案来说，基本上都能够在多个开发者对同一个文件进行变更的时候发出合并的警告。

　　但让我们来看一下，这个解决方案是否真正能够克服数据库方面的各种挑战，并且避免各种可能的风险呢：

• 确保所有的数据库代码都被涵盖 —— 由于开发者或DBA编写了脚本，因此他们能够确保所有数据库代码都被涵盖。
• 确保以版本控制库作为唯一的信任源 —— 并非如此。因为开发者和DBA能够直接登录（任何环境的）数据库，并且直接在数据库中进行变更。