系列图书推荐
华章程序员书库
- 软件安全工程..
- Java TCP/IP Socket编程(原书第2版)..
- 团队制胜:掌握软件项目成功主动权..
- PERL实例精解(原书第4版)..
- VSTO开发者指南..
- Java测试新技术:TestNG和高级概念..
- VSTO开发者指南[赠品]..
- OpenGL编程指南(原书第6版)..
- CMMI成功项目管理:7个CMMI过程域..
- SQL查询初学者指南（原书第2版）..
- CMMI成功项目管理:7个CMMI过程域[赠品]..
- SQL查询初学者指南（原书第2版）[赠品]..
- 安全编程代码静态分析..
- 敏捷软件开发(原书第2版)..
- 持续集成:软件质量改进和风险降低之道(第18届Jol..
- Web应用程序快速开发使用TurboGears..
- 代码质量(注释版)..
- MySQL开发者SQL权威指南..
- EJB 3.0专家编程..
相关图书推荐
同类热销商品
您的浏览历史
持续集成:软件质量改进和风险降低之道(第18届Jolt震撼大奖图书) (08年度畅销榜TOP50)[按需印刷]
![持续集成:软件质量改进和风险降低之道(第18届Jolt震撼大奖图书) (08年度畅销榜TOP50)[按需印刷]](http://images.china-pub.com/ebook35001-40000/38003/zcover.jpg?2010-1-31 22:05:50)
点击看大图
基本信息
- 原书名： Continuous Integration: Improving Software Quality and Reducing Risk
- 原出版社： Addison-Wesley Professional
- 作者： (美)Paul M.Duvall Steve Matyas Andrew Glover [作译者介绍]
- 译者： 王海鹏;贾立群[同译者作品]
- 丛书名： 华章程序员书库
- 出版社：机械工业出版社
- ISBN：9787111229216
- 上架时间：2008-1-17
- 出版日期：2008 年1月
- 开本：16开
- 页码：218
- 版次：1-1
- 所属分类：
计算机 > 软件工程及软件方法学 >
软件质量、软件测试及维护
内容简介回到顶部↑
本书全面深入地讨论持续集成的各个方面。本书介绍了一种增加项目可见性、降低项目失败风险的有效实践。许多软件开发的资深人士认定，这种方法非常不错。本书除了介绍持续集成的基本原则和工具之外，也介绍了测试驱动、代码审查、数据库集成、信息反馈等实践和工具。书中的各种主题介绍了今天在持续集成领域中运用的各种方法，帮助读者衡量需要进行的折衷。
作译者回到顶部↑
本书提供作译者介绍
Paul M.Duvall是Stelligent公司的CTO。Stelligent公司是一家咨询公司，通过优化软件开发过程，帮助开发团队可靠地、快速地开发出更好的软件。他基本上担任过软件开发项目中的所有职务，从开发者到测试者再到架构师和项目经理。他写过很多书，经常在http://testearly.com上写日志。
.. << 查看详细
.. << 查看详细
目录回到顶部↑
译者序
Martion Fowler序
Paul Julius序
前言
作者简介
贡献者简介
第一部分 CI的背景知识：原则与实践
第1章 启程
1.1 针对每次变更构建软件
开发人员
版本控制库
CI服务器
构建脚本
反馈机制
集成构建计算机
1.2 CI的特征
源代码编译
数据库集成
测试
审查
Martion Fowler序
Paul Julius序
前言
作者简介
贡献者简介
第一部分 CI的背景知识：原则与实践
第1章 启程
1.1 针对每次变更构建软件
开发人员
版本控制库
CI服务器
构建脚本
反馈机制
集成构建计算机
1.2 CI的特征
源代码编译
数据库集成
测试
审查
译者序回到顶部↑
软件项目开发有两大难题：一是确定软件的需求，即确定目标；二是确定目前离目标还有多远，即确定剩余的工作量。第二个问题就是项目缺少可见性的问题，对于它的讨论“人月神话”做出了“巨大贡献”。当一个项目经理或一名开发者说已经完成了80%的任务，您必须保持审慎的态度。因为剩下的20%可能还需要80%的时间，甚至永远也不能完成。您可能迟迟不能拿到可以部署的软件，对此所有人都无能为力，只能表示深深的遗憾。这确实让专业软件开发者的声誉蒙羞。但是对于大型软件开发这样的复杂工作，我们的经验确实显得有些不够。.
本书向我们介绍了一种增加项目可见性、降低项目失败风险的有效实践经验。许多软件开发的资深人士认定，这种方法非常不错。我们不必把宝全部押在最后那一次“大爆炸”式的集成上，而是采用“早集成、常集成”的策略。这样做可以减少缺陷引入和缺陷发现之间的时间，提高开发效率，降低风险。您对项目报告中提到的百分比将有更大的信心，而且任何时候，您都可以得到一个可以部署的软件。虽然功能可能还没有全部实现，但它是可用的！
本书向我们揭示了这样一个道理：如果一件事很难，而您又必须做，不妨经常去做，每次做一点点。其实这也是古老的“分而治之”思想的一种应用。正所谓“滴水穿石，跬步千里”。..
敏捷软件开发的许多实践都是互相关联的。持续集成在与其他实践结合时，才能将它的效用发挥到极致。本书除了介绍持续集成（Continuous Integration，CI）的基本原则和工具之外，也介绍了测试驱动、代码审查、数据库集成、信息反馈等实践和工具。人（思想）、过程和自动化工具完美结合，以形成一个和谐的开发生态环境。如果您一直在追求效率更高的软件项目管理方法，我相信本书一定能给您带来一些启发和灵感。
一本好书使您改变。它将改变您的思想，您看待问题的角度和方式，最终，它将改变您的行为。然而，所有具有重要意义的改变都不会在一夜之间发生。改变随时都在发生，但按照您的意志去领导变革却很难。如果您相信这种变革必须发生，不妨朝着这个方向去努力，经常改变，每次改变一点点。
软件业中没有银弹，不可能有某种东西在短时间内让您的开发效率提高10倍。但是我们也很容易发现不同个人和不同团队之间的开发效率相差巨大，不止10倍。那些软件高手和明星团队就像职业围棋选手，他们高得惊人的效率是多年用心改进实践的结果。
参加本书翻译工作的人员除封面署名外还有：王海燕、李国安、周建鸣、范俊、张海洲、谢伟奇、林冀、钱立强、甘莉萍。在本书的翻译过程中，我学到了很多，因此郑重地向大家推荐它。如果本书对于您改进软件开发实践有所帮助，我将十分高兴。
王海鹏
丁亥年秋于上海...
本书向我们介绍了一种增加项目可见性、降低项目失败风险的有效实践经验。许多软件开发的资深人士认定，这种方法非常不错。我们不必把宝全部押在最后那一次“大爆炸”式的集成上，而是采用“早集成、常集成”的策略。这样做可以减少缺陷引入和缺陷发现之间的时间，提高开发效率，降低风险。您对项目报告中提到的百分比将有更大的信心，而且任何时候，您都可以得到一个可以部署的软件。虽然功能可能还没有全部实现，但它是可用的！
本书向我们揭示了这样一个道理：如果一件事很难，而您又必须做，不妨经常去做，每次做一点点。其实这也是古老的“分而治之”思想的一种应用。正所谓“滴水穿石，跬步千里”。..
敏捷软件开发的许多实践都是互相关联的。持续集成在与其他实践结合时，才能将它的效用发挥到极致。本书除了介绍持续集成（Continuous Integration，CI）的基本原则和工具之外，也介绍了测试驱动、代码审查、数据库集成、信息反馈等实践和工具。人（思想）、过程和自动化工具完美结合，以形成一个和谐的开发生态环境。如果您一直在追求效率更高的软件项目管理方法，我相信本书一定能给您带来一些启发和灵感。
一本好书使您改变。它将改变您的思想，您看待问题的角度和方式，最终，它将改变您的行为。然而，所有具有重要意义的改变都不会在一夜之间发生。改变随时都在发生，但按照您的意志去领导变革却很难。如果您相信这种变革必须发生，不妨朝着这个方向去努力，经常改变，每次改变一点点。
软件业中没有银弹，不可能有某种东西在短时间内让您的开发效率提高10倍。但是我们也很容易发现不同个人和不同团队之间的开发效率相差巨大，不止10倍。那些软件高手和明星团队就像职业围棋选手，他们高得惊人的效率是多年用心改进实践的结果。
参加本书翻译工作的人员除封面署名外还有：王海燕、李国安、周建鸣、范俊、张海洲、谢伟奇、林冀、钱立强、甘莉萍。在本书的翻译过程中，我学到了很多，因此郑重地向大家推荐它。如果本书对于您改进软件开发实践有所帮助，我将十分高兴。
王海鹏
丁亥年秋于上海...
前言回到顶部↑
在我刚刚参加工作的时候，我看到杂志上有一张整页的广告，展示了键盘上的一个键，类似Enter键，上面标着“Integrate”（集成）（参见图1）。键下面的文字是“假如一切如此容易。”我已记不清楚这个广告是谁为了什么而做的，但它打动了我的心。在软件开发方面，我曾想，这当然永远不会实现，因为在我们的项目里，我们会花几天的时间在“集成地狱”中挣扎，在接近项目里程碑的时候尝试将大量软件组件拼凑起来。但是我喜欢这个想法，所以我剪下了这张广告，把它贴在我的墙上。对我来说，它代表了我成为一名高效率的软件开发者的主要目标之一：将重复的、容易出错的过程自动化。而且，它包含我的梦想，即将软件集成变成项目中的“小事一桩”（Martin Fowler曾这样说）—只是自然发生的事情。持续集成（CI）可以帮助您将项目中的集成变成小事一桩。.
请考虑软件项目中的一些典型的开发过程：编译代码、通过数据库定义数据并操作数据、进行测试、复查代码，最后部署软件。另外，团队肯定需要就软件的状态进行沟通。请想像一下如果您可以按一个键就完成这些过程。
本书向您展示了如何创建一个虚拟的集成按钮，将许多软件开发过程都自动化。而且，我们介绍了如何持续地按下这个按钮，从而减少创建可部署的应用程序时的风险，如较晚才发现缺陷，低品质的代码等。在创建CI系统时，许多过程都被自动化，在每次修改开发的软件时，都执行这些过程。
什么是持续集成
集成软件的过程不是新问题。在一个人开发的项目中，依赖外部系统又比较少的话，软件集成不会成为太大的问题，但是随着项目复杂度的增加（即使只增加一个人），就会对集成和确保软件组件能够一起工作提出更多的要求—要早集成，常集成。等到项目快结束时才来集成会导致各种各样的软件品质问题，解决这些问题代价很大，常常会导致项目延期。CI以较小增量的方式迅速地解决这些风险。
在Martin Fowler热门的文章《Continuous Integration》（持续集成）中，他将CI描述为：
……一种软件开发实践，即团队的成员经常集成他们的工作，通常每个成员每天至少集成一次—这导致每天发生多次集成。每次集成都通过自动化的构建（包括测试）来验证，从而尽快地检测出集成错误。许多团队发现这个过程会大大减少集成问题，让团队能够更快地开发内聚的软件。
根据我的经验，这意味着：
·所有开发者都先要在他们自己的工作站上执行私有构建，然后再将他们的代码提交到版本控制库中，从而确保他们的变更不会导致集成构建失败。
·开发者每天至少向版本控制库提交一次代码。
·集成构建每天在一台独立的计算机上进行多次。
·每次构建都必须100%通过测试。
·生成可以进行功能测试的产品（如WAR、配件、可执行程序等）。
·修复失败的构建是优先级最高的事情。
·某些开发者复查构建生成的报告，如编码标准报告和依赖分析报告，寻找可以改进的地方。
本书讨论了CI中自动化的方面，因为您会从自动化重复的、容易出错的过程中得到许多好处。但是，正如Fowler所指出的，CI就是经常集成工作的过程，这不一定需要自动化的过程。我们相信，既然已经有许多工具让CI成为自动化的过程，那么使用CI服务器来自动化CI实践就是一种有效的方式。不管怎样，也许手工集成的方式（利用自动化的构建）很适合您的团队。
快速反馈
持续集成增加了您获得反馈信息的机会。这样，您每天都能多次了解项目的状态。CI可以用来减少引入缺陷和修复缺陷之间的时间，从而改进总体软件品质。
开发团队不应该相信因为CI系统自动化了，就可以避免集成问题。如果团队只使用自动化的工具来编译源代码，就更是如此。有些人把编译称为“构建”，实际上不是的（参见第1章）。有效的CI实践包含的东西比工具多得多。它包括本书中介绍的实践，如经常向版本控制库提交代码，立即修复失败的构建以及使用独立的集成构建计算机等。
CI的实践支持快速反馈。如果应用了有效的CI实践，您可以每天多次了解到正在开发的软件的健康状况。而且，CI与重构、测试驱动开发等实践配合得挺好，因为这些实践的中心思想都是进行小的变更。从本质上来说，CI提供了一张安全网，确保变更能够与软件的其他部分一起工作。从更高的层面上讲，CI增加了团队整体的信心，减少了项目所需的人工，因为它通常是一个无人执守的过程，在软件发生变更时执行。
请考虑软件项目中的一些典型的开发过程：编译代码、通过数据库定义数据并操作数据、进行测试、复查代码，最后部署软件。另外，团队肯定需要就软件的状态进行沟通。请想像一下如果您可以按一个键就完成这些过程。
本书向您展示了如何创建一个虚拟的集成按钮，将许多软件开发过程都自动化。而且，我们介绍了如何持续地按下这个按钮，从而减少创建可部署的应用程序时的风险，如较晚才发现缺陷，低品质的代码等。在创建CI系统时，许多过程都被自动化，在每次修改开发的软件时，都执行这些过程。
什么是持续集成
集成软件的过程不是新问题。在一个人开发的项目中，依赖外部系统又比较少的话，软件集成不会成为太大的问题，但是随着项目复杂度的增加（即使只增加一个人），就会对集成和确保软件组件能够一起工作提出更多的要求—要早集成，常集成。等到项目快结束时才来集成会导致各种各样的软件品质问题，解决这些问题代价很大，常常会导致项目延期。CI以较小增量的方式迅速地解决这些风险。
在Martin Fowler热门的文章《Continuous Integration》（持续集成）中，他将CI描述为：
……一种软件开发实践，即团队的成员经常集成他们的工作，通常每个成员每天至少集成一次—这导致每天发生多次集成。每次集成都通过自动化的构建（包括测试）来验证，从而尽快地检测出集成错误。许多团队发现这个过程会大大减少集成问题，让团队能够更快地开发内聚的软件。
根据我的经验，这意味着：
·所有开发者都先要在他们自己的工作站上执行私有构建，然后再将他们的代码提交到版本控制库中，从而确保他们的变更不会导致集成构建失败。
·开发者每天至少向版本控制库提交一次代码。
·集成构建每天在一台独立的计算机上进行多次。
·每次构建都必须100%通过测试。
·生成可以进行功能测试的产品（如WAR、配件、可执行程序等）。
·修复失败的构建是优先级最高的事情。
·某些开发者复查构建生成的报告，如编码标准报告和依赖分析报告，寻找可以改进的地方。
本书讨论了CI中自动化的方面，因为您会从自动化重复的、容易出错的过程中得到许多好处。但是，正如Fowler所指出的，CI就是经常集成工作的过程，这不一定需要自动化的过程。我们相信，既然已经有许多工具让CI成为自动化的过程，那么使用CI服务器来自动化CI实践就是一种有效的方式。不管怎样，也许手工集成的方式（利用自动化的构建）很适合您的团队。
快速反馈
持续集成增加了您获得反馈信息的机会。这样，您每天都能多次了解项目的状态。CI可以用来减少引入缺陷和修复缺陷之间的时间，从而改进总体软件品质。
开发团队不应该相信因为CI系统自动化了，就可以避免集成问题。如果团队只使用自动化的工具来编译源代码，就更是如此。有些人把编译称为“构建”，实际上不是的（参见第1章）。有效的CI实践包含的东西比工具多得多。它包括本书中介绍的实践，如经常向版本控制库提交代码，立即修复失败的构建以及使用独立的集成构建计算机等。
CI的实践支持快速反馈。如果应用了有效的CI实践，您可以每天多次了解到正在开发的软件的健康状况。而且，CI与重构、测试驱动开发等实践配合得挺好，因为这些实践的中心思想都是进行小的变更。从本质上来说，CI提供了一张安全网，确保变更能够与软件的其他部分一起工作。从更高的层面上讲，CI增加了团队整体的信心，减少了项目所需的人工，因为它通常是一个无人执守的过程，在软件发生变更时执行。
评论交流
共有20人开贴评论 23人参与评论 16人参与打分 查看
评价等级：
发表于：2008-3-18 15:55:00
当一个项目经理或一名开发者说已经完成了80%的任务，您必须保持审慎的态度。因为剩下的20%可能还需要80%的时间，甚至永远都不能完成。”
上面这段话来自于《持续集成——软件质量改进和风险降低之道》的译者序。仔细想想，此话说得相当有道理：程序员是一群自信而乐观的人，总是以为自己已经考虑到了方方面面，所编写的模块万无一失、无懈可击。哪怕遇到了问题，也总会找到理由：是不是需求或是别人出了问题——一句最为流行的Developer应对Tester的Bug Report的话就是，“It is not a bug, but it is a feature.”。
不过即使程序员有千万种理由为自己的模块洗清了一切的“罪名”，但客户需要的上线或发布时间却仍旧无声地等在那里，不以任何人的借口而改变。
回到本文开始的那段译者序文字中，那“剩下的20%”究竟要用来做什么呢？为什么“可能还需要80%的时间”呢？
答案就是集成。虽然流行的软件开发理论已经把模块/组件之间的耦合程度降低到了最低，且有无数种类似单元测试的“流程”保证这每一个独立模块功能的正确性，不过当把这些堪称“完美”的模块集合成一个整体系统时，还是会不停地出现各种问题？
OK，让我们停止探讨为什么会发生这样的情况之类无谓的探讨，而是去看看应该怎样解决这个问题，并最终保证产品的发布时间和质量——毕竟问题已经发生了。
——持续集成。
持续集成能够把最终的一次大规模的集成调试过程分散到项目开发时间表的每一周、每一天、甚至每个小时。让项目中的各个人员都能够随时掌握当前的整体进度，并迅速发现集成过程中出现的问题并进行解决。
这本《持续集成——软件质量改进和风险降低之道》的第一部分就详细介绍了持续集成的理念、相关流程以及做法。
目前来看，持续集成似乎看起来非常不错，不是吗？
可是，一次集成并不是说句话就能搞定的——构建、部署、测试、生成测试报告、反馈……种种操作将会占用大量的人工。难道还需要专门派人负责每天的集成吗？
因此，将所有的步骤自动化，就是实现持续集成中最为重要的问题。
《持续集成——软件质量改进和风险降低之道》的第二部分则给出了一个完善的自动化持续集成流程，让持续集成从一句空谈变为实实在在的、具有可操作性的规范。
不过是一本200页左右的小书，却已经毫无遗漏地将持续集成的点点滴滴娓娓道来。若你正在为这方面的问题苦恼，不妨尝试从中找到一些答案。
陈黎夫
2005年毕业于上海交通大学计算机科学专业 ?005年作为软件开发工程师加入微软Windows Live Hotmail团队 吩斡肟⒘讼乱淮鶨mail系统Windows Live Mail，以及Windows Live Calendar等产品。 飞贸SP.NET、CSS、JavaScript等Web相关技术并有着多年的开发、设计经验。
上面这段话来自于《持续集成——软件质量改进和风险降低之道》的译者序。仔细想想，此话说得相当有道理：程序员是一群自信而乐观的人，总是以为自己已经考虑到了方方面面，所编写的模块万无一失、无懈可击。哪怕遇到了问题，也总会找到理由：是不是需求或是别人出了问题——一句最为流行的Developer应对Tester的Bug Report的话就是，“It is not a bug, but it is a feature.”。
不过即使程序员有千万种理由为自己的模块洗清了一切的“罪名”，但客户需要的上线或发布时间却仍旧无声地等在那里，不以任何人的借口而改变。
回到本文开始的那段译者序文字中，那“剩下的20%”究竟要用来做什么呢？为什么“可能还需要80%的时间”呢？
答案就是集成。虽然流行的软件开发理论已经把模块/组件之间的耦合程度降低到了最低，且有无数种类似单元测试的“流程”保证这每一个独立模块功能的正确性，不过当把这些堪称“完美”的模块集合成一个整体系统时，还是会不停地出现各种问题？
OK，让我们停止探讨为什么会发生这样的情况之类无谓的探讨，而是去看看应该怎样解决这个问题，并最终保证产品的发布时间和质量——毕竟问题已经发生了。
——持续集成。
持续集成能够把最终的一次大规模的集成调试过程分散到项目开发时间表的每一周、每一天、甚至每个小时。让项目中的各个人员都能够随时掌握当前的整体进度，并迅速发现集成过程中出现的问题并进行解决。
这本《持续集成——软件质量改进和风险降低之道》的第一部分就详细介绍了持续集成的理念、相关流程以及做法。
目前来看，持续集成似乎看起来非常不错，不是吗？
可是，一次集成并不是说句话就能搞定的——构建、部署、测试、生成测试报告、反馈……种种操作将会占用大量的人工。难道还需要专门派人负责每天的集成吗？
因此，将所有的步骤自动化，就是实现持续集成中最为重要的问题。
《持续集成——软件质量改进和风险降低之道》的第二部分则给出了一个完善的自动化持续集成流程，让持续集成从一句空谈变为实实在在的、具有可操作性的规范。
不过是一本200页左右的小书，却已经毫无遗漏地将持续集成的点点滴滴娓娓道来。若你正在为这方面的问题苦恼，不妨尝试从中找到一些答案。
陈黎夫
2005年毕业于上海交通大学计算机科学专业 ?005年作为软件开发工程师加入微软Windows Live Hotmail团队 吩斡肟⒘讼乱淮鶨mail系统Windows Live Mail，以及Windows Live Calendar等产品。 飞贸SP.NET、CSS、JavaScript等Web相关技术并有着多年的开发、设计经验。
)
加载中...| 我要写评论 |
| 查看所有评论交流(共20条) |