豆瓣上有此书的介绍,《持续集成:软件质量改进和风险降低之道》。此书还有配套web站点,提供了此书更新、代码示例和其他材料。
第一部分 CI的背景知识:原则与实践
第一章 启程
一次构建:不止是一次编译(或是动态语言中的某种称谓)。一次构建可能包含编译、测试、审查和部署以及其他一些事情。一次构建是将源代码放在一起,并验证软件可以作为一个一致的单元运行的过程。
涉及到的工具和参与人员包括:开发人员、版本控制库(如subversion)、CI服务器(如CruiseControl)、构建脚本(如Ant)、反馈机制(如email)、集成构建计算机。
CI的特征:与版本控制器系统的连接;构建脚本;某种类型的反馈机制;集成源代码变更的过程。
其子过程包括:源代码编译;数据库集成;测试;审查(如静态和动态分析);部署;文档与反馈。
第二章 引入持续集成
CI的价值在于:
- 减少风险
- 缺陷的检测和修复变得更快
- 软件的健康程度可以测量
- 减少假定
- 减少重复过程
- 减少重复过程的劳动,让人们有时间做更多的需要动脑筋的、更高价值的工作。
- 通过对一些重要过程(如测试盒数据库集成)自动化,克服项目中的某些成员对实现改进的抵制。
- 在任何时间、任何地点生成可部署的软件
- 增强项目的可见性
- 有效地决策:CI系统可以对当前的构建状态和品质指标提供及时的信息。
- 注意到趋势:如构建成功或失败、总体品质以及其他相关的项目信息。
- 对开发团队的软件产品建立起更强大的产品信心
阻碍团队使用CI的原因:
- 增加了维护CI系统的开销
- 变化太大
- 失败的构建太多
- 额外的硬件/软件成本
- 开发者应该执行这些动作
对于在项目中实现CI的团队和个人很有好处的7项实践:
- 经常提交代码:进行小的变更;在每个任务之后进行提交。
- 不要提交无法构建的代码
- 立即修复无法集成的构建
- 编写自动化的开发者测试
- 必须通过所以测试和审查
- 执行私有构建
- 避免签出无法构建的代码
第三章 利用CI减少风险
CI能够缓解的一些关键风险:
- 没有可部署的软件:利用CI系统随时构建可部署的软件。创建一个可重复的构建过程,使用版本控制库中的所有软件资产。
- 很晚才发现缺陷:每次变更时都执行开发者测试,这样就能够在软件开发生命周期中尽早发现缺陷。
- 缺少项目可见性:经常运行构建,随时了解项目的健康状况。如果有效地应用CI实践,项目的状态就不再是一个问题。
- 低品质的软件:在每次变更时执行测试和审查,这样就能通过了解复杂程度、重复情况、设计、代码覆盖率和其他因素发现可能进入代码中的潜在缺陷。
第四章 针对每次变更构建软件
执行单命令构建 – Martin Fowler说:“把所有需要的东西都放到源代码版本控制库中,以便于您通过单个命令就能构建整个系统。”
将构建脚本从IDE中分离 – 因为:(1)每个开发者可能使用不同的IDE,找出每个IDE中配置文件的差别会很困难;(2)CI服务器必须在无人干预的情况执行自动化的构建,因此开发者执行的自动化构建脚本,同样也应该能够由CI服务器执行。
集中放置软件资产 – 一种方法是使用版本控制库来存放所有文件,除了代码,还包括:
- 组件,包括源文件和库文件;
- 第三方组件,如JAR文件、库、DLL等
- 配置文件
- 初始化应用程序的数据文件
- 构建脚本和构建环境设置
- 某些组件的安装脚本
让构建快速失败 – 好的构建知道如何快速地失败。在构建的许多部分都成功之后再失败,这让人很恼火,而且您在确定失败的目标时也会失去宝贵的时间。创建快速失败构建的主要步骤如下:集成组件;运行真正的单元测试;执行其他自动化的过程。
构建类型:
- 私有构建:开发者在向版本控制库提交代码之前,要先进行私有构建。
- 集成构建:集成构建集成项目团队向版本控制库中的主线提交的变更。
- 发布构建:准备好发布给用户的软件。
构建触发机制:
- 用户驱动:由某人手工发起构建
- 定期执行:由时间驱动,不论是否发生了变更。
- 轮训变更:一个进程以固定的时间间隔唤醒,从版本控制库中签出变更。如果检测到变更,它就执行集成构建。
- 事件驱动:与轮训变更类似,但是是由版本控制库出发的,基于实现定义好的变更事件。
使用CI服务器 – 如果您打算自己写一个CI服务器,可能需要包含下面的一些功能:
- 以特定的时间间隔轮训版本控制库中的变更
- 定期执行某种操作
- 标识出“安静期”,在这段时间内项目不进行集成构建
- 支持不同的构建脚本工具,包括命令行工具
- 向相应人员发送电子邮件
- 显示以前构建的历史
- 显示一个web信息面板,这样每个人都可以查看集成构建的信息
- 为不同的项目支持多个版本控制系统
执行快速构建 – 快速反馈对CI是很关键的。集成构建的时间越短,您就能越快收到反馈信息。可以按如下方式分析并减少构建时间:
- 收集构建测量数据
- 分析构建测量数据
- 选择并实现改进
- 重新评估,有必要则再次重复这个过程
集成构建测量的指标:
- 编译时间
- 源代码行数(SLOC)
- 审查的种类数
- 平均组装生成时间
- 测试执行时间(根据分类)
- 成功构建和失败构建的比例
- 审查时间
- 部署时间
- 重建数据库的时间
- 集成构建计算机系统资源和使用情况
- 版本控制系统的负载
可以采取的改进方法:
- 使用专门的集成构建计算机
- 增强集成构建计算机的硬件能力
- 改进测试性能
- 安排集成构建的顺序
- 优化基础设施
- 优化构建过程
- 单独构建系统组件
- 改进软件审查的性能
- 执行分布式集成构建
Pingback:Scrum/Agile Starter Kit | BE AGILE & LEAN