数据库开发的持续集成 - 方法和流程
文/itrust 出处/博客园
决定使用
Castle ActiveRecord来开发新的系统，基于面向对象的思想将数据库设计转化为对象的代码设计，就可以将程序的持续集成开发自然引入数据库开发。再辅以liquibase，数据库的持续集成开发就可行了，也解决了数据库部署的问题。同时在引入liquibase后，数据库版本管理以及部署和升级也就简化了。
1 开发方法使用领域驱动设计方法(Domain Driven Design)开发数据库,以面向对象的设计方法设计数据库表，具体方法包括：
- 直接设计数据库实体类，然后使用ActiveRecord创建数据库表
- 数据库表的一切属性（列类型、长度、约束、索引，表间关系等全部在实体类中设计）
- 数据库访问层基于实体类实现，业务逻辑优先选择数据库访问层通过代码实现，除此之外的在存储过程中实现
2 数据库开发架构
附件:
您所在的用户组无法下载或查看附件- 每个数据库开发人员必须在本地数据库实例上进行设计、编码和测试
- 持续集成服务器通过监视SVN服务器上用户提交行为触发持续集成过程，在基线数据库上验证、部署新的数据库结构
- 持续集成数据库上的基线数据库
- 其结构（包含数据库静态数据）为当前已发布系统的结构
- 只有持续集成过程能够修改基线数据库
- 开发人员只能通过持续集成过程来修改该数据库
- 开发人员可将基线数据库视为产品数据库，可通过将其与本地数据库进行比较得到数据库部署脚本
3 数据库开发流程3.1 本地开发流程 附件:
您所在的用户组无法下载或查看附件- 所有设计和测试都在本地数据库上进行
- 每一个访问层函数和较为复杂的实体类（如含外键关系）应有测试案例，必须通过测试
- 数据库部署脚本的生成
- 在有多人设计数据库时需注意及时获取SVN上部署脚本在本地执行，与基线数据库保持一致
- 使用liquibase对比本地数据库和基线数据库，生成部署脚本
- 注意：已发布的数据库部署脚本不可更改
3.2 持续集成流程 附件:
您所在的用户组无法下载或查看附件- 数据库包括两个CC项目:studio和trunk，都采用该流程
- 上图中任一流程发生错误都导致持续集成失败
- 通过数据库文档可查看所有数据库结构修改日志
4 编码原则- 放弃使用Sql Server的domain,rule,default等（rule和default在2005中不被支持）
- 使用ActiveRecord的Nested Data替代domain
- 通过对Nested Data所进行ActiveRecord定义实现rule和default
- 谨慎使用视图和存储过程
考量我目前的新系统开发，这个方法和流程还是可行的，估计在实践中还会有很多问题出现，希望发现问题的园友不吝赐教。
| 感谢原创者的辛勤劳动，希望对您有所帮助，转载请注明原出处。 |
