CI中数据库版本控制Dbdeploy原理介绍及使用分享.docx

CI中数据库版本控制——DbDeploy原理介绍及使用分享目前系统多人开发模式下，由于新需求的加入，数据库表结构变更比较频繁，而一个人对数据库的操作如果未及时同步将会影响到其他人的开发及测试人员的测试，更严重的是导致线上应用程序发生异常甚至出现漏洞，因此急需一个比较好的工具和最佳实践来做数据库版本控制。为项目组内每个成员建立数据库沙盒环境，利用DbDeploy可以很好的解决这样的问题，将sql脚本作为源码一起做版本控制，利用命令自动运行sql脚本，减少敏捷开发中持续集成的成本。如图：1. 简介dbDeploy是thoughtworks公司开发的开源数据库版本控制工具，控制数据库变更，并且在项目开发过程中，不断验证数据库脚本的正确性，在项目部署之初，可以方便的部署数据库。它的主要原理是通过逐步建立建表语句（表现为多个文件，如001_create_table.sql，002_insert_data.sql，003_insert_data.sql），通过数据库表里的记录记录当前已经包含的建表语句，在再次更新数据库脚本时递增的更新，从而保证持续集成的正确性。dbdeploy支持ant、maven和命令行接口；支持mysql，hsql，SQL_Server，oracle等数据库。官网：/Google网址：/p/dbdeploy/其他类似的数据库版本控制工具：MIGRATEdb, Ruby ActiveRecoredMigration, DB Ghost, sundog等。2. 基本原理及规则2.1 基本原理查看changelog中已经存在的脚本编号，并生成需要执行的所有脚本编号；批量执行尚未执行的脚本，更新changelog表；在整个执行过程中，如果有指定outputfile，则将已经执行的sql脚本输出到outputfile中，否则默认改变数据库，不输出已经执行的sql脚本；2.2 规则及约定在数据库中建名为’changelog’的表，用于控制数据库变更；2.0版本表结构如下：DROP TABLE IF EXISTS `changelog `;CREATE TABLE changelog ( change_numberbigint(20) NOT NULL, delta_setvarchar(10) NULL, start_dt timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, complete_dt timestamp NULL default NULL, applied_byvarchar(100) NOT NULL, descriptionvarchar(500) NOT NULL,PRIMARY KEY (`change_number`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;3.0之后changelog表结构变更为CREATE TABLE changelog (change_number INTEGER NOT NULL,complete_dt TIMESTAMP NOT NULL,applied_by VARCHAR(100) NOT NULL,description VARCHAR(500) NOT NULL,PRIMARY KEY (`change_number`));用于指明数据库变更的sql脚本--约定规则①数据库变更的脚本应尽量保证原子性；也就是一个脚本中应尽量仅包含一条不可拆分的DDL(CREATE,ALTER etc)命令（避免出错时处理比较复杂，需要回滚之前很多步骤）；当然对于DML语言（UPDATE,INSERT etc）可多包含多条，因为它们都是以事务的方式运行。②必须保证每次对数据库的修改都保存为sql脚本；③sql脚本的命名规范，必须是以数字开头以指明此sql脚本在所有脚本中的执行顺序；如001_create_table.sql，002_insert_data.sql，003_insert_data.sql；注意：sql脚本的命名要尽量能表达此脚本执行内容的含义，例如：004_add_index_on_custId_column_of_table_cust_index.sql.④可以在sql脚本中加入回滚部分，出错时自动执行回滚语句；如001_create_table.sqlCREATE TABLE FOO (FOO_ID INTEGER NOT NULL,FOO_VALUE VARCHAR(30));ALTER TABLE FOO ADD CONSTRAINT PK_FOO PRIMARY KEY (FOO_ID);--//@UNDODROP TABLE FOO;⑤