读书：持续集成软件质量改进和风险降低之道
Continuous Integration
经常发生这种事：开发者修改源代码，dba修改了表定义 构建部署团队修改了配置文件 接口团队修改了规范。
如何利用持续反馈，测试（单元测试，自动化浏览器测试），部署（自动化构建部署），审查（和同事或者架构师经常代码审查），数据库集成来是实现持续集成?
要经常进行集成构建：编译 重新创建数据库 执行自动测试发邮件和审查 部署软件并接收反馈发邮件。
问你自己构建的工程？
开发的代码复杂程度如何？
应用程序是否仍然满足性能要求？
自动测试覆盖了多少代码？
最后一次变更以后，是否通过了所有的测试？
最近的开发是否存在问题？
持续的构建，持续的反馈，开发周期内得到修正？
CI特点
连接版本控制系统
构建脚本（脚本自动化）
反馈机制（电子邮件）
整合源码变更的过程（编译和单元测试）
自动化【数据库集成、测试、审查、部署】和反馈
单元测试 组件测试 系统测试 负载性能测试 安全测试
自动化数据库集成
自动化测试（单元函数，组件，系统，功能）
自动化代码审查（静态分析+动态分析）
自动化部署（解决了人为过程中的瓶颈）
有些过程，人为操作反而会心累又出错，所以自动化
【对于开发者，要减少假设，假定，想到任何可能出现的情况】
自动化测试的脚本要构建到版本库中，整个可持续的集成都要完全自动化
项目过程中存在的各种基本风险
重复代码是有风险的，粘贴复制存在风险；
累死代码副本需要维护的时候，带来忽略；
硬编码；
对你自己项目过程中所思考的
！！！！！！！！！！！！！
哪些是手工的，是否可以自动化？
构建过程中，重建数据库和测试数据？
每次软件变更执行自动化回归测试？功能，集成。负载，性能测试？
哪些代码没有对应测试？是否使用覆盖率工具？
软件代码重复百分比是多少？设法减少百分比
当前代码是否遵守软件架构？
通知构建版本和部署版本可以接受测试了？
当前的软件结构图是怎么样？如何跟新来的解释软件架构？
【以前我以为测试不重要，因为之前公司一直是人为的功能流程测试。现在看来，开发和自动化测试(单元，功能，性能，负载，集成)一阴一阳；测试驱动开发；】
构建CI服务器？
构建脚本
——》清理
——》编译源代码
——》集成数据库
——》执行测试
——》执行审查
——》部署软件
为了执行构建更加容易，设立集成目录：
需求目录
设计目录
源代码目录
文档目录
测试目录
部署目录
开发-测试-文档编写共行
构建的触发机制：
用户驱动：手工发起
定期执行：定时任务
轮询变更：从版本库中签出变更，ci工具触发
事件驱动：监测到版本库更新就检测，版本库触发
使用ci 构建计算机服务器
软件资产统一放到版本库中
集成服务器-集成按钮？
构建花费多少时间？是否尝试减少时间？提高反馈速度？
构建频率？每周？每晚上？发生变更时？
很多项目使用共享数据库，开发者对共享数据库操作极有可能影响其他团队成员的工作。所以开发者要有自己本地的数据库沙盒。
要准备数据库集成自动化脚本。
利用版本控制库共享数据库资产（包含数据库配置，测试数据，实体关系图，存储过程和函数，删除创建表和视图的DDL,包括约束条件和触发器）
在版本库中专门新建目录存放数据库资产（开发目录和测试目录都要分开）。
持续集成中的自动化测试
开发和测试一阴一阳，不可分割，同样重要；测试驱动开发。
自动化测试分为一下标准测试
单元测试：没有外部依赖关系
组件测试：数据库，文件系统，网络终端：典型的是需要底层数据库支持生成测试数据，甚至跨越架构边界；依赖关系更多；执行的是web下面的业务层
系统测试：测试外部接口，web页面，web服务selenium
功能测试：以客户的视觉和行为验收测试
为缺陷编写测试。
将测试用例限制为一个断言。
测试资产要提交到版本库中持续集成。
源代码的可靠取决于测试覆盖率；
测试价值取决于执行频率。
持续集成中的持续审查
降低代码复杂度
减少重复代码
持续进行设计复查
判断代码覆盖率
自己小黄鸭调试方法
静态代码分析，动态代码分析
结对编程
自动化代码审查能解决80%的问题
代码的路径数和缺陷之间存在关系
不稳定性 = 传出耦合/（传入耦合+传出耦合）
1 确定单元测试的执行频率？偶尔/定期/持续/项目部署前
2 如何检查单元测试 组件测试 系统测试的覆盖率？
3 是否监控代码的复杂度？是
4 持续的自动化设计复查？工具？
5 代码审查自动化？
6 是否监控代码的重复情况
7 是否产生覆盖率报告？
持续集成中的持续部署
持续集成的目的就是搞随时随地可发布的软件。
你写的软件真的可以随时随地可发布么？
假如外包软件，在期望时间内最终向用户提交高品质能工作的软件，而不是噩梦发行版，失去控制，每个人惊慌失措、失眠、白头发…
高效的创建能工作的软件是专业软件开发者存在的理由。持续集成使得平时工作可能稍微繁琐，但是发布的工作量变小而且稳定性提高。
项目持续部署：
1 是否拥有回滚发行版本的能力？
2 构建版本控制库中的构建版是否打上标签？
3 候选发行版 是否整套自动化测试和人工测试？
4 团队如何处理缺陷修复的发布？
5 版本控制标签和构建版本标签是否相关？
6 构建是否提供反馈报告
7 是否命令行单条命令部署软件？
8 能否从版本库中取出所有软件资产进行构建部署？
9 能否在干净的计算机上正确安装并运行？
10 是否有缺陷追踪系统？能否自动生成报告？
持续集成中的项目持续反馈
一切都在变化，不断拥抱变化
在正确的时间（每天/每周/问题发生时），以正确的方式（电子邮件/短信），讲正确的信息（构建状态/审查报告/测试结果）发送给正确的人（构建负责人，技术负责人，项目经理，产品经理，业务分析师，开发者）。
是否有太多的人过于频繁的收到反馈信息？
反馈是否及时？
信息是否适量？
项目团队在地理位置上是否是分布式的？信息发射器自动化？
反馈机制有趣么？
持续反馈设备cfd,向项目风险承担者通知构建是否失败，比如代码重复率超过百分比。
