持续集成:软件质量改进和风险降低之道.pdf

持续集成:软件质量改进和风险降低之道.pdf
 

书籍描述

编辑推荐
《持续集成:软件质量改进和风险降低之道》首先从最基础的东西开始,讨论了CI的概念和实践,然后进一步讨论了CI系统执行的其他有效的过程,如数据库集成、测试、审查、部署和反馈。通过超过40个CI相关的实践和不同语言环境下的应用示例,读者可以明白CI将导致更快速的软件开发,在开发生命周期中的每一步都能得到可部署的软件,而且减少了缺陷引入和发现之间的时间,节约了开发时间,降低了开发成本。通过成功地实现CI,开发者可以减少风险和重复的手工操作过程,开发团队可以更好地了解项目的状态。

作者简介
作者:(美国)杜瓦尔(Paul M.Duvall) (美国)迈耶斯(Stephen M.Matyas Ⅲ) (美)格洛弗(Andrew Glover) 译者:王海鹏

杜瓦尔(Paul M.Duvall)是Stelligent公司的CTO。Stelligent公司是一家咨询公司,他们通过优化软件开发过程,帮助开发团队可靠地、快速地开发出更好的软件。他几乎担任过软件开发项目中的所有职务,从开发者到测试者再到架构师和项目经理。Paul向各个行业的客户提供咨询,包括金融业、房地产业、政府、医疗卫生业,以及大型的独立软件提供商。他是许多知名软件会议的特邀讲演者。他为IBM developerWorks撰写了一系列的文章,名为"Automation for the People",他是NFJS 2007 Anthology(Pragmatic Programmers,2007)的合著者,也是UML 2 Toolkit(Wiley,2003)的贡献作者。他是临床研究数据管理系统和方法的发明者之一,这个系统和方法正在申请专利。他经常在www.testearly.com和www.integratebutton.com上写日志。
迈耶斯(Stephen M.Matyas Ⅲ)是AutomateIT的副总裁。AutomateIT是5AMSolutions公司的一个服务机构,它帮助组织机构通过自动化来改进软件开发。Steve在应用软件工程方面有多重背景,他的客户包括商业客户和政府客户。Steve担任过许多种不同的角色,从业务分析师和项目经理到开发者、设计者和架构师。他是UML 2 Toolkit(Wiley,2003)的贡献作者。他实践了许多迭代增量式的方法,包括敏捷方法和Rational Unified Process(RUP)。他的大部分第一手的职业经验来自于Java/J2EE定制软件开发和服务,在方法学、软件品质和过程改进方面具有特珠的要求。他拥有弗吉尼亚理工大学的计算机科学学士学位。
格洛弗(Andrew Glover)是Stelligent公司的总裁。Stelligent公司是一家咨询公司,他们通过优化软件开发过程,帮助开发团队可靠地、快速地开发出更好的软件。Andy经常在北美的各种会议上作为讲演嘉宾,他也是No Fluff Just Stuff Software Symposium小组的讲演者。他还是Groovy in Action(Manning,2007),Java Testing Patterns(Wiley,2004)及NFJS 2006 Anthology(Pragmatic Programmers,2006)的合著者之一。他也是一些在线文章的作者,这些文章发布在IBM的developerWorks,O'Reilly的ONJava、ONLamp和Dev2Dev门户站点上。他经常在www.thediscoblog.com和www.testearly.com上写有关软件品质的日志。
王海鹏,1994年毕业于华东师范大学,软件开发者,独立的咨询顾问、培训讲师、译者。拥有20年编程经验,已翻译二十余本软件开发书籍。目前主要感兴趣的领域是软件架构和方法学,致力于提高软件开发的品质和效率。

目录
出版说明
译者序
Martin Fowler序
Paul Julius序
前言
作者简介
贡献者简介
第1部分 CI的背景知识:原则与实践
第1章 启程
1.1 针对每次变更构建软件
开发人员
版本控制库
CI服务器
构建脚本
反馈机制
集成构建计算机
1.2 CI的特征
源代码编译
数据库集成
测试
审查
部署
文档与反馈
1.3 本章小结
1.4 问题
第2章 引入持续集成
2.1 CI生活中的一天
2.2 CI的价值是什么
减少风险
减少重复过程
生成可部署的软件
增强项目的可见性
建立起更强大的产品信心
2.3 什么阻碍了团队使用CI
2.4 如何进行"持续"集成
2.5 项目应该在何时以何种方式实现CI
2.6 集成的演进
2.7 CI如何与其他开发实践配合
2.8 CI需要多少时间架设
2.9 CI与您
2.10 经常提交代码
2.11 不要提交无法构建的代码
2.12 立即修复无法集成的构建
2.13 编写自动化的开发者测试
2.14 必须通过所有测试和审查
2.15 执行私有构建
2.16 避免签出无法构建的代码
2.17 本章小结
2.18 问题
第3章 利用CI减少风险
3.1 风险:没有可部署的软件
场景:"在我的机器上是行的"
场景:与数据库同步
场景:点错了
3.2 风险:很晚才发现缺陷
场景:回归测试
场景:测试覆盖
3.3 风险:缺少项目可见性
场景:"您收到了备忘录吗?"
场景:不能使软件可见
3.4 风险:低品质的软件
场景:坚持编码标准
场景:维持架构
场景:重复的代码
3.5 本章小结
3.6 问题
第4章 针对每次变更构建软件
4.1 自动化构建
4.2 执行单命令构建
4.3 将构建脚本从IDE中分离
4.4 集中放置软件资产
4.5 创建一致的目录结构
4.6 让构建快速失败
4.7 针对所有环境构建
4.8 构建类型和触发机制
构建类型
构建触发机制
触发构建
4.9 使用专门的集成构建计算机
4.10 使用CI服务器
4.11 执行手工集成构建
4.12 执行快速构建
收集构建测量数据
分析构建测量数据
选择并实现改进
4.13 分阶段构建
重新评估
4.14 这对您如何生效
4.15 本章小结
4.16 问题
第2部分 创建全功能的CI系统
第5章 持续数据库集成
5.1 自动化数据库集成
创建数据库
操作数据库
创建一段构建数据库的结合脚本
5.2 使用本地数据库沙盒
5.3 利用版本控制库共享数据库资产
5.4 持续数据库集成
5.5 让开发者能够修改数据库
5.6 开发团队共同关注修复失败构建
5.7 让DBA成为开发团队的一员
5.8 数据库集成和集成按钮
测试
审查
部署
反馈与文档
5.9 本章小结
5.10 问题
第6章 持续测试
6.1 自动化单元测试
6.2 自动化组件测试
6.3 自动化系统测试
6.4 自动化功能测试
6.5 对开发者测试分类
6.6 先执行较快的测试
单元测试
组件测试
系统测试
6.7 为缺陷编写测试
6.8 让组件测试可重复
6.9 将测试用例限制为一个断言
6.10 本章小结
6.11 问题
第7章 持续审查
7.1 审查与测试的区别
7.2 应该以怎样的频度执行审查
7.3 代码测量指标:历史
7.4 降低代码复杂度
7.5 持续进行设计复查
7.6 通过代码审查维持组织机构的标准
7.7 减少重复的代码
使用PMD—CPD
使用Simian
7.8 判断代码覆盖率
7.9 持续评估代码品质
覆盖率检查频度
覆盖率与性能
7.10 本章小结
7.11 问题
第8章 持续部署
8.1 随时随地发布可工作的软件
8.2 为库中的资产打上标签
8.3 得到干净的环境
8.4 为每一个构建版打上标签
8.5 执行所有的测试
8.6 创建构建反馈报告
8.7 回滚构建的过程能力
8.8 本章小结
8.9 问题
第9章 持续反馈
9.1 所有正确的东西
正确的信息
正确的人
正确的时间
正确的方式
9.2 使用持续反馈机制
电子邮件
SMS(文本消息)
Ambient Orb和X10设备
Windows任务条
声音
宽屏显示器
9.3 本章小结
9.4 问题
后记:CI的未来
附录A CI资源
A.1 持续集成WEB站点/文章
A.2 CI工具/产品资源
A.3 构建脚本资源
A.4 版本控制资源
A.5 数据库资源
A.6 测试资源
A.7 自动化审查资源
A.8 部署资源
A.9 反馈资源
A.10 文档资源
附录B 评估CI工具
B.1 评估工具时的考虑
功能性
与环境的兼容性
可靠性
寿命
易用性
B.2 自动化构建工具
B.3 构建计划安排工具
B.4 结论
参考文献

文摘
版权页:

持续集成:软件质量改进和风险降低之道

插图:

持续集成:软件质量改进和风险降低之道

CI的实践与其他软件开发实践是互补的,如开发者测试、坚持编码标准、重构和小发行版本。不论您是在使用RUP、XP、RUP结合XP、SCRUM、Crystal或其他任何一种方法学,都可以采用CI的实践。下面的列表总结了CI的实践是怎样促进其他实践的。
■开发者测试:开发者编写测试时通常使用某种xUnit框架,如JUnit或NUnit。这些测试可以通过构建脚本自动执行。由于CI的实践鼓励每次对软件进行改动时就执行构建,而自动化测试又是构建的一部分,所以CI就使得每次对软件进行修改时,都会对全部代码执行自动化的回归测试。
■坚持编码标准:编码标准是开发者在开发项目时必须遵守的一组规范。在许多项目中,确保遵守编码规范基本上是一个手工过程,通过代码复查来执行。CI可以在每次发生变更时执行一段构建脚本,通过运行一些自动化的静态分析工具,根据已建立的编码标准审查源代码,报告标准的遵守情况。
■重构:根据Fowler所说的,重构是"这样一个过程,它在不改变代码的外部行为的情况下,对软件系统进行修改,改进它的内部结构。"这使代码更容易维护,并带来其他好处。CI可以通过在每次构建时运行审查工具,确定可能的问题,从而实现对重构的支持。
■小发行版本:这项实践让测试人员和用户能够按他们的需要的频度,得到可以工作的软件,因为软件集成每天都会进行许多次,基本上任何时候都可以得到一个发行版本。当CI系统就位后,得到一个发行版本是不用花多少力气的。
■共同拥有代码:每个开发者都可以修改软件系统的每一个部分。这避免了"知识孤岛",即对于系统的特定部分,只有一个人了解相关的知识。CI实践通过确保遵守编码标准,持续执行回归测试,对共同拥有代码提供了支持。

内容简介
《持续集成:软件质量改进和风险降低之道》全面深入地讨论持续集成的各个方面,介绍了一种增加项目可见性、降低项目失败风险的有效实践。此外,还介绍了测试驱动、代码审查、数据库集成、信息反馈等实践和工具。全书列举了持续集成系统的优缺点,以及如何使用持续集成系统、什么时候使用等,可操作性极强。Jolt大奖素有"软件业之奥斯卡"的美称,《持续集成:软件质量改进和风险降低之道》精选自Jolt历届获奖图书,以植根于开发实践中的独到工程思想与杰出方法论为主要甄选方向。

购买书籍

当当网购书 京东购书 卓越购书

PDF电子书下载地址

相关书籍

搜索更多