系列图书推荐
华章程序员书库
- Java TCP/IP Socket编程(原书第2版).. 【购买】
- 团队制胜:掌握软件项目成功主动权.. 【购买】
- PERL实例精解(原书第4版).. 【购买】
- VSTO开发者指南.. 【购买】
- Java测试新技术:TestNG和高级概念.. 【购买】
- OpenGL编程指南(原书第6版).. 【购买】
- CMMI成功项目管理:7个CMMI过程域.. 【购买】
- SQL查询初学者指南（原书第2版）.. 【购买】
- 安全编程代码静态分析.. 【购买】
- 敏捷软件开发(原书第2版).. 【购买】
- 持续集成:软件质量改进和风险降低之道(第18届Jol.. 【购买】
- Web应用程序快速开发使用TurboGears.. 【购买】
- 代码质量(注释版).. 【购买】
- MySQL开发者SQL权威指南.. 【购买】
- EJB 3.0专家编程.. 【购买】
- Groovy入门经典.. 【购买】
- Groovy入门经典(赠品).. 【购买】
- EJB 3.0专家编程(赠品).. 【购买】
- 代码质量(注释版)(赠品).. 【购买】
相关图书推荐
同类热销商品
- 寒江独钓:Windows内核安全编程(china-pub首发)..
- Google Android SDK开发范例大全(台湾天珑书局09..
- MySQL性能调优与架构设计(china-pub首发)..
- Google Android开发入门与实战..
- Windows高级调试(china-pub 首发)..
- Windows 内核情景分析--采用开源代码ReactOS(上、..
- 程序员的自我修养--链接、装载与库(china-pub 首..
- 亮剑.NET:.NET深入体验与实战精要(china-pub首发..
- 大象--Thinking in UML(china-pub全国独家首发) ..
- 深入搜索引擎--海量信息的压缩、索引和查询 (chin..
您的浏览历史
持续集成:软件质量改进和风险降低之道(第18届Jolt震撼大奖图书) (08年度畅销榜TOP50) [绝版]
点击看大图
基本信息
【评 价】
(共 18 条) 参与评论 |
| 【原 书 名】 Continuous Integration: Improving Software Quality and Reducing Risk |
| 【原出版社】 Addison-Wesley Professional |
| 【作 者】(美)Paul M.Duvall;Steve Matyas;Andrew Glover [同作者作品] [作译者介绍] |
| 【译 者】 王海鹏;贾立群[同译者作品] |
| 【丛 书 名】 华章程序员书库 |
| 【出 版 社】 机械工业出版社 【书 号】 9787111229216 |
| 【上架时间】 2008-1-17 |
| 【出版日期】 2008 年1月 【开 本】 16开 【页 码】 218 【版 次】1-1 |
| 【所属分类】 | 计算机 > 软件工程及软件方法学 > 软件质量、软件测试及维护 |
编辑推荐
【内容简介】
本书全面深入地讨论持续集成的各个方面。本书介绍了一种增加项目可见性、降低项目失败风险的有效实践。许多软件开发的资深人士认定，这种方法非常不错。本书除了介绍持续集成的基本原则和工具之外，也介绍了测试驱动、代码审查、数据库集成、信息反馈等实践和工具。书中的各种主题介绍了今天在持续集成领域中运用的各种方法，帮助读者衡量需要进行的折衷。【编辑推荐】
本书适合软件开发人员及团队阅读，也适合大专院校相关专业师生参考。本书向软件开发者展示了如何将集成从一件痛苦的事情变成日常开发过程的一部分。正如作者所说的，关键就在子利用持续集成的实践和技术经常进行集成。
本书首先从最基础的东西开始讲起，讨论了持续集成的概念和实践，然后进一步讨论了持续集成系统执行的其他有效过程，如数据库集成，测试、审查。部署和反馈。通过40多个持续集成相关的实践和不同语言环境下的应用示例，读者可以明白持续集成将导致更快速的软件开发，在开发生命周期中的每一步都能得到可部署的软件，而且减少了引入缺陷和发现缺陷之间的时间，节约了开发时间，降低了开发成本。通过成功地实现持续集成，开发者可以减少风险和重复的手工操作过程，开发团队可以更好地了解项目的状态。
本书主要内容：
·如何在软件开发项目中让集成变成“小事一桩”。
·如何减少构建软件时的重复过程。
·在团队中有效地实现持续集成的实践和技术。
·减少很晚发现缺陷、低品质软件和项目缺少可见性的风险。
·对市场上不同持续集成服务器和相关软件的评估。
·本书的配套网站www．integratebutton．com提供了更新内容和代码示例。
【作译者介绍】
本书提供作译者介绍
Paul M.Duvall是Stelligent公司的CTO。Stelligent公司是一家咨询公司，通过优化软件开发过程，帮助开发团队可靠地、快速地开发出更好的软件。他基本上担任过软件开发项目中的所有职务，从开发者到测试者再到架构师和项目经理。他写过很多书，经常在http://testearly.com上写日志。
.. << 查看详细
【目录信息】
译者序Martion Fowler序
Paul Julius序
前言
作者简介
贡献者简介
第一部分 CI的背景知识：原则与实践
第1章 启程
1.1 针对每次变更构建软件
开发人员
版本控制库
CI服务器
构建脚本
反馈机制
集成构建计算机
1.2 CI的特征
源代码编译
数据库集成
测试
<< 查看详细目录
【译者序】
软件项目开发有两大难题：一是确定软件的需求，即确定目标；二是确定目前离目标还有多远，即确定剩余的工作量。第二个问题就是项目缺少可见性的问题，对于它的讨论“人月神话”做出了“巨大贡献”。当一个项目经理或一名开发者说已经完成了80%的任务，您必须保持审慎的态度。因为剩下的20%可能还需要80%的时间，甚至永远也不能完成。您可能迟迟不能拿到可以部署的软件，对此所有人都无能为力，只能表示深深的遗憾。这确实让专业软件开发者的声誉蒙羞。但是对于大型软件开发这样的复杂工作，我们的经验确实显得有些不够。.本书向我们介绍了一种增加项目可见性、降低项目失败风险的有效实践经验。许多软件开发的.. << 查看译者序
【前言】
在我刚刚参加工作的时候，我看到杂志上有一张整页的广告，展示了键盘上的一个键，类似Enter键，上面标着“Integrate”（集成）（参见图1）。键下面的文字是“假如一切如此容易。”我已记不清楚这个广告是谁为了什么而做的，但它打动了我的心。在软件开发方面，我曾想，这当然永远不会实现，因为在我们的项目里，我们会花几天的时间在“集成地狱”中挣扎，在接近项目里程碑的时候尝试将大量软件组件拼凑起来。但是我喜欢这个想法，所以我剪下了这张广告，把它贴在我的墙上。对我来说，它代表了我成为一名高效率的软件开发者的主要目标之一：将重复的、容易出错的过程自动化。而且，它包含我的梦想，即将软件集成变成项目中的“小.. << 查看前言>>进入在线免费试读
【相关资源】
· 程序员的7种武器(正则表达式、编程语言、数据库、算法、软件调试、开发环境)
持续集成:软件质量改进和风险降低之道(第18届Jolt震撼大奖图书) (08年度畅销榜TOP50) -所有相关信息
评论交流
共有18人开贴评论
19人参与评论
15人参与打分
查看
 |
6人 | 40% |
用户平均打分
|
|||
|
5人 | |||||
|
3人 | |||||
|
0人 | |||||
|
1人 |
评价等级：
发表于：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相关技术并有着多年的开发、设计经验。
加载中...
 |
我要写评论 |
| 查看所有评论交流(共18条) |