数据库开发的持续集成 - 方法和流程

本系列文章目录
    数据库开发的持续集成 - Sql Server 部署升级工具
    数据库开发的持续集成 - Sql Server数据库结构比较
    数据库开发的持续集成 - 方法和流程
    数据库开发的持续集成 - Liquibase的简介和应用
    数据库的持续集成 - CruiseControl.Net的项目配置

决定使用Castle ActiveRecord来开发新的系统，基于面向对象的思想将数据库设计转化为对象的代码设计，就可以将程序的持续集成开发自然引入数据库开发。再辅以liquibase，数据库的持续集成开发就可行了，也解决了数据库部署的问题。同时在引入liquibase后，数据库版本管理以及部署和升级也就简化了。
当然，如果你不使用ActiveRecord开发数据库，也完全可以基于liquibase来实现自己的持续集成，只需稍作调整，将我流程中实体类的部分改换成数据库表的设计和测试即可。

1 开发方法

使用领域驱动设计方法(Domain Driven Design)开发数据库,以面向对象的设计方法设计数据库表，具体方法包括：

• 直接设计数据库实体类，然后使用ActiveRecord创建数据库表
• 数据库表的一切属性（列类型、长度、约束、索引，表间关系等全部在实体类中设计）
• 数据库访问层基于实体类实现，业务逻辑优先选择数据库访问层通过代码实现，除此之外的在存储过程中实现

2 数据库开发架构

• 每个数据库开发人员必须在本地数据库实例上进行设计、编码和测试
• 持续集成服务器通过监视SVN服务器上用户提交行为触发持续集成过程，在基线数据库上验证、部署新的数据库结构
• 持续集成数据库上的基线数据库
  • 其结构（包含数据库静态数据）为当前已发布系统的结构
  • 只有持续集成过程能够修改基线数据库
  • 开发人员只能通过持续集成过程来修改该数据库
  • 开发人员可将基线数据库视为产品数据库，可通过将其与本地数据库进行比较得到数据库部署脚本

3 数据库开发流程

3.1 本地开发流程

• 所有设计和测试都在本地数据库上进行
• 每一个访问层函数和较为复杂的实体类（如含外键关系）应有测试案例，必须通过测试
• 数据库部署脚本的生成
  • 在有多人设计数据库时需注意及时获取SVN上部署脚本在本地执行，与基线数据库保持一致
  • 使用liquibase对比本地数据库和基线数据库，生成部署脚本
  • 注意：已发布的数据库部署脚本不可更改

3.2 持续集成流程
3.2.1 Trunk流程

• 此流程先升级基线数据库GTCA，然后在基线数据库上做持续集成（以保证新的程序集和升级脚本兼容以发布的产品系统）
• 上图中任一流程发生错误都导致持续集成失败，数据库回滚到集成前的状态
• 通过数据库文档可查看所有数据库结构修改日志

3.2.2 Studio流程

• 此流程通过创建临时数据库GTCATest，开展测试工作

4 编码原则

• 放弃使用Sql Server的domain,rule,default等（rule和default在2005中不被支持）
• 使用ActiveRecord的Nested Data替代domain
• 通过对Nested Data所进行ActiveRecord定义实现rule和default
• 谨慎使用视图和存储过程

考量我目前的新系统开发，这个方法和流程还是可行的，估计在实践中还会有很多问题出现，希望发现问题的园友不吝赐教。

Update 20080620 关于liquibase,请参见数据库开发的持续集成 - Liquibase的简介和应用
Update 20080625 根据实际应用的情况，修正了一下流程, 并发布数据库的持续集成-CruiseControl.Net的配置
     主要的修正在于考虑测试代码在本地，持续集成服务器上的Studio项目和Trunk项目中都能够使用，且满足下列要求
     * Trunk项目中测试代码直接在升级后的基线数据库上测试（以保证新发布的代码和脚本在兼容已发布的产品数据库），因此不允许修改数据库结构
     * Studio项目在测试数据库上测试