持续交付
目的
快速发现错误
“快速失败”，在对产品没有风险的情况下进行测试，并快速响应；
每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
最大限度地减少风险，降低修复错误代码的成本；
将重复性的手工流程自动化
- 让工程师更加专注于代码；
保持频繁部署，快速生成可部署的软件；
防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。
增强开发人员对软件产品的信心
提供项目的能见度，方便团队成员了解项目的进度和成熟度；
帮助建立更好的工程师文化；
准则
持续集成不是工具，而是一种实践
所有人投入一定的精力
修复那些破坏了应用的任意源代码修改是团队优先级最高的任务
有限性依赖于团队的纪律
实现方式
准备工作
版本控制
产品代码
测试代码
数据库脚本
构建脚本
部署脚本
自动化构建
前提条件
- 人和计算机都能通过命令行自动执行应用的构建、测试以及部署过程
目标
自动化执行整个过程，能对出现问题的做审计
构建脚本应该与应用代码同等对待
构建过程应该容易理解、维护、调试和协作
持续集成系统
工具
- Jenkins
文档记录和自动化持续集成构建服务器的配置
工作步骤
- 7个步骤的流程图随后可以画一个
期望结果
- 环境只要与我的持续集成环境一直，我的软件就可以工作
前提条件
频繁提交
每天至少几次
代码的主干-分支
提交到主干
不推荐使用分支
分支无法实现持续集成
创建全面的自动化测试集合包
单元测试
对象
每个方法
每个函数
一组方法和函数之间的调用
十分钟内完成所有测试
组件测试
测试几个组件的行为
可能需要连接数据库、访问文件系统、外部接口
需要较长时间完成测试
验收测试
测试是否满足预定义的业务需求
其它方面
容量
有效性
安全性
整个应用最好运行在类生产环境
运行一整天或者更长
构建和测试过程维护在更短的时间内
理想的时间：十分钟内，最好五分钟内，越短越好
效率工具
JUnit
NUnit
将测试分成若干阶段
第一阶段：提交阶段
编译软件
执行单元测试
构建部署包
冒烟测试（可选）
第二阶段
验收测试
集成测试
性能测试（可选）
任务可以并行
大于半小时就需要通过投入更多运算资源降低时间消耗
管理开发工作区
从一个已知最新的正确版本的起点开始
精细的配置管理是基础
注意依赖的库文件
应用可以在开发机上跑起来
自动化测试（含冒烟测试）能在开发机上跑通
使用持续集成软件
基本操作
动作
第一部分：按时间间隔执行工作流水线
第二部分：展示流水线运行结果
铃声和口哨
使用声光电等提示错误提示手段
第一时间了解构建状态
现在可以发送：Slack等即时线上通讯手段
相关分析
测试覆盖率
重复代码
编码标准的遵从
健康指标
最佳实践
构建失败后停止新代码提交
提交前在本地和持续集成服务器测试执行所有目标测试
保证构建一直是绿的
预提交测试
pretested commit
personal build
preflight build
在本地测试将要提交的代码
等提交通过之后再继续工作
构建必须成功后才能回家
随时准备回滚到前一个旧版本
- 不能在构建失败的情况下提交代码
回滚前要规定一个修复时间
- 例如：十分钟无法修复代码就回归到前一个版本
不要将失败的测试注释掉
为自己所导致的问题负责
使用测试驱动开发
推荐实践
极限编程开发实践
若违背了架构原则，就让构建失败
若测试运行变慢了，就让构建失败
本地测试容忍时间：秒级
尽早解决测试的性能问题
若编译告警或代码风格有误，就让测试失败
代码检查工具
Simian
CheckStyle
FindBugs
提高代码质量
小结
快速发布。能够应对业务需求，并更快地实现软件价值。
编码->测试->上线->交付的频繁迭代周期缩短，同时获得迅速反馈；
高质量的软件发布标准。整个交付过程标准化、可重复、可靠。
整个交付过程进度可视化，方便团队人员了解项目成熟度；
更先进的团队协作方式。从需求分析、产品的用户体验到交互 设计、开发、测试、运维等角色密切协作，相比于传统的瀑布式软件团队，更少浪费。
持续集成提高了团队的生产效率
需要良好的团队记录
相关基础设施
一个巨大的可视化指示器
结果报表系统，供给给测试团队的安装包
为项目经理提供项目资料监测的应用或报表
用持续部署的流水线，为所有人员提供能延伸到生产环境的一键式部署
持续集成-实践
实践工具
- Jenkins
