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