持续集成数据库

持续数据库集成（Continuous Database Integration ,CDBI）即每次项目的版本控制库中发生变更时，重建数据库和测试数据。

数据库代码包括：DDL、DML、配置文件等。

在本质上与系统的其他源代码没有差别，实际上数据库的构建可以纳入CI系统，与数据库集成有关的制品应该放在版本控制库中，进行严格的测试和审查以确定是否遵守策略，并可通过构建脚本生成。

自动化集成

数据库管理员（Database Administrator DBA）所具备的分析技能需要多年才能掌握，但却常常把时间花在执行低级命令上，这是对人才的严重浪费，而开发过程中等待DBA修改数据库也成了妨碍CI提倡的持续开发方式的瓶颈。

日常工作中，需要重复进行但可通过持续集成改进的内容有： 删除数据、创建新数据库、插入系统数据、插入测试数据、迁移数据库及数据、多个环境下建立数据库实例、修改列属性和约束条件、修改测试数据、修改存储过程（包括函数和触发器）、取得对不同环境的访问权、备份\恢复大量数据等。

创建数据库一般步骤：

1.数据库权限

2.表

3.自增序列（sequence）

4.视图

5.存储过程和函数

6.触发器

按照数据库定义的类型（如表、视图、函数）或按子系统（如属性和应用程序）来组织目标和脚本比较容易。

创建一段构建数据库的结合脚本

数据库集成的结合脚本将执行DLL语句和数据操作语言（DML）语句。利用结合构建脚本使数据库集成自动化，持续执行，对数据库或源代码进行修改后就执行。

数据库沙盒

当开发者对共享数据库结构进行修改时，可能会不小心影响其他团队成员工作，导致其他开发私有构建失败，没有资源未每个开发者提供一个数据库可以为每个开发者提供一个独立的schema,或使用免费的清凉的开源数据库代替。

通过数据库集成自动化，每个人都能在自己的工作站上创建一个本地数据库实例，创建一个数据库“沙盒”，使自己对数据库进行变更和测试不会影响到他人。

创建的本地数据库沙盒必须支持多数据库环境，通过自动化修改构建脚本参数，执行一个命令即可为不同的数据环境提供数据。

使用版本控制库共享数据资产

确保所有数据集成都由构建脚本管理，所有数据库资产放入版本控制库，测试并审查数据库脚本和代码，利用版本控制库确保共享数据库的单一来源。将DDL和DML脚本提交到版本控制库，其他开发就能执行同样的脚本，进行重建数据库和测试数据。

数据库资产包括：

1.删除、创建表和视图的DDL，包括约束条件和触发器

2.存储过程和函数

3.实体关系图

4.针对不同环境的测试数据

5.具体的数据库配置

拥有上述内容，可以做到： 1）快速从头创建整个数据库； 2）可追踪数据库变更的历史； 3）减少对DBA的操作依赖； 4）对数据库进行修改，执行私有构建提交到版本控制库中，并知道执行后的反馈信息。

当然，在数据库需要进行大规模改动是是需要好几个专业人员一起执行，花费长时间才能完成的，最好创建一个任务分支来想版本库提交变更，而不是直接在主线上修改，让团队工作集体慢下来。

开发均可修改

每个开发均可修改任何一部分数据库脚本不意味着开发者都会去修改这些数据库脚本。每个开发有自己的数据库沙盒所以每个人都能修改本地的数据库然后将变更提交到版本控制库。

将数据库和源代码同等对待，意味着可能会因为数据库的错误导致构建失败，根据持续集成快速修复原则，无论是什么导致构建失败，都应及时修复它。

DBA成为开发的一员有助于改善这些状况，除了帮助查找持续数据库集成的问题，不再执行删除表、重建表、创建测试环境、分配访问权限等繁琐工作后，他们可以花更多时间在改进数据库性能、改进SQL性能、数据规范化及其他增值活动。

快速持续构建

快速执行构建

构建的可伸缩性指的是当集成和分析代码数量增加时，构建系统处理的能力。构建的性能指的是构建的持续时间。理想情况下，代码越来越多，CI系统也不应该显著地降低性能。 但是，频繁地提交代码是持续集成所必须的，可以这样分析并变少构建时间：

1.收集构建测量数据 编译时间、源代码行数（SLOC）、审查种类数、平均组装生成时间、测试执行时间、成功构建和失败构建的比例、审查时间、部署时间、重建数据库时间、集成构建计算机系统资源和使用情况、版本控制系统负载等。

2.分析构建测量数据 改进方法有：

1）使用专门的集成构建计算机（可伸缩性高、性能高、难度低）

2）增强集成构建计算机的硬件能力（可伸缩性高、性能中、难度低）

3）改进测试性能（可伸缩性低、性能高、难度中）

4）安排集成构建的顺序（可伸缩性低、性能中、难度低）

5）优化基础设施（可伸缩性中、性能中、难度高）

6）优化构建过程（可伸缩性低、性能中、难度低）

7）单独构建系统组件（可伸缩性低、性能中、难度中）

8）改进软件审查的性能（可伸缩性低、性能高、难度低）

9）执行分布式集成构建（可伸缩性高、性能高、难度高）

3.选择并实现改进

1）对CPU、硬盘或内存进行升级

2） 将一些处理转移到其他系统上

3）删除不需要的系统进程

4）将自动测试按类别分开（单元测试、组建测试、系统测试），在不同时间执行这些测试

5）基于审查工具的结果，重构测试

6）对于单元测试环境中很难测试或很复杂的组件，使用模拟/桩（mock/stub）对象的方式执行测试

7）将运行时间长的集成测试放到单独一个测试套件中

8）并发执行测试

9）根据构建类型执行不同测试，提交构建后有次级构建、完整的集成构建或发布构建

4.重新评估，再次重复这个过程

建议少量多次持续集成构建时间不超过10分钟。

分阶段构建

1.检查基础设施 系统基础设施、网络性能、虚拟专用网络速度满、各种硬件软件问题等可能导致构建较慢。通过分析并改进基础设施资源，减少构建时间。

2.优化构建过程 代码量过大可执行增量式构建而不是完全构建；

需要集成源代码和其他相关文件的构建可将系统分解为较小的子系统，单独构建系统组建；

审查性能可能导致CI变慢，可通过删除无用无必要审查、减少重复审查、降低某些身材频率等改进软件审查的性能；

如果代码规模很大，且已尝试提高处理器速度、增加内存等操作，可执行分布式集成构建。（解决方案较为复杂）

问题&解决

1.我的项目代码很多，CI好像不方便？

项目越大越需要CI。如果是因为构建时间过程，可以定期执行那些运行时间长的过程或分阶段执行。长时间执行的过程通常包括：组建测试、系统测试、功能测试、审查等，可以将代码分成独立子项目进行集成构建。

2.源代码在多个版本控制库中该怎么办？

CI服务器提供管理构建依赖关系的能力，一个项目发生构建后强制另一个项目开始构建。

3.构建经常失败，是因为做错了什么吗？

执行私有构建，尽可能在开发机器上模拟集成构建，再将变化提交到版本控制库中。

实践自检

1.是否能通过自动化构建过程一键重新创建数据库？

2.数据库自动化脚本事都提交到了版本控制库中？

3.项目中的每个人是否都能利用自动化重建数据库？

4.是否能利用版本控制系统回到以前版本的数据库？

5.代码变更提交到版本控制库时变更是否与最新的数据库一起集成测试？

6.数据库存储和触发过程和触发器的行为是否通过执行测试验证？

7.自动化数据库集成过程是否可以配置？