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

发布时间：2022-05-29 发布人：admin 分类：说明书资料大小：21.57M 资料格式：pdf 举报版权申诉

guansir-4190739-4744302542877199367.pdf-第1页.png

第1页 / 共245页

guansir-4190739-4744302542877199367.pdf-第2页.png

第2页 / 共245页

guansir-4190739-4744302542877199367.pdf-第3页.png

第3页 / 共245页

guansir-4190739-4744302542877199367.pdf-第4页.png

第4页 / 共245页

guansir-4190739-4744302542877199367.pdf-第5页.png

第5页 / 共245页

guansir-4190739-4744302542877199367.pdf-第6页.png

第6页 / 共245页

guansir-4190739-4744302542877199367.pdf-第7页.png

第7页 / 共245页

guansir-4190739-4744302542877199367.pdf-第8页.png

第8页 / 共245页

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

译者序

Martin Fowler 序

Paul Julius序

前言

第一部分 CI的背景知识：原则与实践

第一章启程

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 问题

第二部分创建全功能的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资源

附录B 评估CI工具

参考文献

译者序软件项目开发有两大难题:一是确定软件的需求，即确定目标 z 二是确定目前离目标还有多远，即确定剩余的工作量。第二个问题就是项目缺少可见性的问题，对于它的讨论"人月神话"做出了"巨大贡献"。当一个项目经理或一名开发者说已经完成了 80% 的任务，您必须保持审慎的态度。因为剩下的 20% 可能还需要 80% 的时间，甚至永远也不能完成。您可能迟迟不能拿到可以部署的软件，对此所有人都无能为力，只能表示深深的遗憾。这确实让专业软件开发者的声誉蒙羞。但是对于大型软件开发这样的复杂工作，我们的经验确实显得有些不够。本书向我们介绍了一种增加项目可见性、降低项目失败风险的有效实践经验。许多软件开发的资深人士认定，这种方陆非常不错。我们不必把宝全部押在最后那一次 "大爆炸"式的集成上，而是采用"早集成、常集成"的策略。这样做可以减少缺陷引人和缺陷发现之间的时间，提高开发效率，降低风险。您对项目报告中提到的百分比将有更大的信心，而且任何时候，您都可以得到一个可以部署的软件。虽然功能可能还没有全部实现，但它是可用的! 本书向我们揭示了这样一个道理:如果一件事很难，而您又必须做，不妨经常去做，每次做一点点。其实这也是古老的"分而治之"思想的一种应用。正所谓"滴水穿石， i圭步千里"。敏捷软件开发的许多实践都是互相关联的。持续集成在与其他实践结合肘，才能将它的效用发挥到极致。本书除了介绍持续集成 (Continuous Integration , CI)的基本原则和工具之外，也介绍了测试驱动、代码审查、数据库集成、信息反馈等实践和工具。人(思想)、过程和自动化工具完美结合，以形成一个和谐的开发生态环境。如果您一直在追求效率更高的软件项目管理方法，我相信本书一定能给您带来一些启发和灵感。一本好书使fg 改变。它将改变您的思想，您看待问题的角度和方式，最终，它将改变您的行为。然而，所有具有重要意义的改变都不会在一夜之间发生。改变随时都在发生，但按照您的意志去领导变革却很难。如果您相信这种变革必须发生，不妨朝着这个方向去努力，经常改变，每次改变一点点。

IV 软件业中没有银弹，不可能有某种东西在短时间内让您的开发效率提高 10倍。但是我们也很容易发现不同个人和不同团队之间的开发效率相差巨大，不止 10倍。那些软件高手和明星团队就像职业围棋选手，他们高得惊人的效率是多年用心改进实践的结果。参加本书翻译工作的人员除封面署名外还有 z 王海燕、李国安、周建鸣、范俊、张海洲、谢伟奇、林冀、钱立强、甘莉萍。在本书的翻译过程中，我学到了很多，因此郑重地向大家推荐它。如果本书对于您改进软件开发实践有所帮助，我将十分高兴。王海鹏丁亥年秋于上海

Martin Fowler 6序在软件行业发展的初期，软件项目中最棘手、最紧张的时刻就是集成。能单独工作的一些模块被组装在一起，然而系统整体却常常失败，而且很难找到失败的原因。但在最近几年里，集成基本上已不再是项目中的痛苦之源，而是变成了"小事一桩"。这种转变的关键在于更为频繁地进行集成。人们曾经认为日构建是一个较难做到的目标。但是今天我接触到的项目每天都集成许多次。很奇怪，如果您遇到很痛苦的事情，似乎一个比较好的建议就是更频繁地去做这件事。关于持续集成，一件有趣的事情就是人们常常会对它产生的影响感到吃惊。我们经常发现人们认为它的好处不大，但它却给项目带来了完全不同的感觉。项目的可见性变得好了很多，因为问题能够更快地检蹦出来。因为引人缺陷和发现缺陷之间的时间变短了，缺陷的发现就更容易，您可以很容易地看看改变了什么，以便帮助您找到问题的根源。与良好的测试程序配合时，可以大大减少缺陷的数量。结果是，开发者在调试上花的时间减少了，在增加功能上花的时间更多了，他们相信自己是在一个坚实的基础上开发软件。当然，光说应该更频繁地集成是不够的，在这个简单的词语后面有一些原则和实践，正是这些原则和实践使得持续集成变成现实。您可以找到一些建议，这些建议在一些书籍中和互联网上都会有(我很自豪，我也在这方面提供过一些内容 ) .但是您必须亲自花力气去寻找。所以我很高兴看到jPaul把这些信息收集起来，成为一本完整的书。对于希望执行这些最佳实践的人来说，这是一本参考手册。和许多简单的实践一样，细节之中包含着许多令人烦恼的东西。在这些年来，我们已经对这些细节有了许多了解，并学会了如何进行处理。这本书汇集了这些经验，为持续集成奠定了坚实的基础，就像持续集成为软件开发奠定了坚实的基础一样。 e Martin Fowler是ThoughtWorks公司的首席科学家，在面向对象分析、 UML模式、软件开发方法学等方面都是世界顶级专家，著名畅销书《分析模式队((U ML精粹》和 4 重构》的作者。

PaulJulius序我一直希望有人能够抽出时间来写这本书，早写比晚写好。私下里说，我总希望这个人就是我。但是我很高兴Paul 、 Steve和 Andy最后能够一起完成这本完整的、经过深思熟虑的专著。我一直技人在持续集成之中，做那些似乎永远也做不完的事情。 2001 年 3 月，我和朋友一起创建了开放源代码项目 CruiseControl ，并成为项目的管理者。在白天的工作中，我在ThoughtWorks提供咨询，利用 CI的原则和工具帮助客户设计、构建和部署测试解决方案。在CruiseControl的邮件列表中， 2003 年开始活动多了起来。我有机会读到几千个不同的持续集成 (Continuous Integration , CI) 故事。软件开发者们遇到的问题各不相同，非常复杂。开发者们完成所有这些工作的理由对我来说越来越清楚了。 CI的好处，如快速反馈、快速部署和可重复的自动化测试，要远大于实现CI的麻烦。但是，在创建这类环境时却很容易忽视这一点。当我们第一次发布 CruiseControl时，我从来没想到过人们会通过一些有趣的方式，利用 CI来改进他们的软件开发过程。 2000年，我在一个大型的J2EE应用程序开发项目中工作，这个项目用到了J2EE规范中提供的所有功能。这个应用程序本身就已够让人吃惊，更不必说它的构建了。所谓构建，我是指编译、测试、打包井执行功能测试。 Ant还处在初期，还没有成为 Java应用程序构建工具的事实标准。我们使用了一套组合的 shell脚本来编译所有东西并执行单元测试。我们使用另一套 shell脚本将所有东西变成可部署的包。最近，我们通过一些手工的步骤来部署 JAR包并执行我们的功能测试。不用说，这个过程变得费时费力，而且经常容易出错。从那时起我就希望创建一个可重复的构建过程，只要按"一个按钮"就可以了 (那是Martin Fowler的热门话题之一) 0 Ant解决了跨平台的构建脚本的问题。我想要的其他东西要能够处理那些烦琐的步骤 z 部署、功能测试以及报告结果。那时，我研究了已有的解决方案，但没有找到我想要的。在那个项目中，我从来没有找到我所希望的东西。那个应用程序成功地完成了开发并投入使用，但我知道事情还可以做得更好。在那个项目和下一个项目之间的时间里，我找到了答案。 Martin Fowler和 Matt

VII Foemmel 刚刚发布了他们关于 CI 的第一篇文章。很幸运，我遇到了另一些 ThoughtWorks 的同事，他们正致力于把Fowler/Foemmel 系统变成可复用的解决方案。我很兴奋，太兴奋了!我知道这就是在上个项目中一直萦绕在我心中的问题的答案。在几周之后，我们已经准备好了所有东西，井在几个已有的项目中开始使用。我甚至拜访 r 一个愿意进行 Beta测试的地方，在一个真正的目标企业中安装了 CruiseControl 的前身。对我来说，再也不会回头了。作为ThoughtWorks的一名顾问，我遇到了一些极为复杂的企业级部署结构。我们的客户根据业界的宣传资料承诺的优势，经常希望得到快速的修复。就像所有技术一样，关于它可以怎样轻易地改变您的企业，实际上存在着一些误导。如果说我从多年的顾问工作中学到了什么，那就是没有什么事情像看起来那么简单。我想告诉客户如何实际地应用 CI的原则。我想强调从开发的"韵律"转变到真正享受到那些好处的重要性。如果开发者每个月只签入一次，不关注自动化的测试，或者并不急于修复失败的构建，那么要完全享受CI的好处就很成问题了。这是否意味着 IT经理们应该先完成向这些实践的转变，再来碰CI呢?不是的。实际上，应用 CI 的实践可以是促成这些改变的最快推进器。我发现，安装像 CruiseControl这样的 CI工具会使软件团队变得积极主动，而不是消极被动。这些改变不会在→夜中发生，您必须有正确的预期一一包括那些涉及的 IT经理。通过对底层原理的深入理解，即使是最复杂的环境也可以变得易于理解，易于测试，而且易于很快地投入生产使用。本书的作者们为您整理好比赛场地。我发现这本书既全面又深入。这本书深入地讨论了 CI最重要的方面，它将帮助读者做出理智的决定。书中的各种主题介绍了今天在CI领域中运用的各种方告，帮助读者衡量需要进行的折衷。最后，我很高兴看到 CI 社区中有这么多的工作被规范化，成为下一步创新的基础。由于这一点，我非常推荐这本书。它是一个重要的资源，利用这些CI魔法，使得企业级应用程序的复杂配置变得有意思。

前在我刚刚参加工作的时候，我看到杂志上有一张整页的广告，展示了键盘上的一个键，类似Enter键，上面标着 "Integrate" (集成) (参见图1)。键下面的文字是"假如一切如此容易。"我已记不清楚这个广告是谁为了什么而做的，但它打动了我的心。在软件开发方面，我曾想，这当然永远不会实现，因为在我们的项目里，我们会花几天的时间在"集成地狱"中挣扎，在接近项目里程碑的时候尝试将大量软件组件拼凑起来。但是我喜欢这个想法，所以我剪下了这张广告，把它贴在我的墙上。对我来说，它代表了我成为一名高效率的软件开发者的主要目标之一:将重复的、容易出错的过程自动化。而且，它包含我的梦想，即将软件集成变成项目中的"小事一桩" (Martin Fowler 曾这样说)一一只是自然发生的事情。持续集成 (CI)可以帮助您将项目中的集成变成小事一桩。 44!叫也咱可 j h 、图 1 集成 a 本书点请考虑软件项目中的一些典型的开发过程:编译代码、通过数据库定义数据并操作数据、进行测试、复查代码，最后部署软件。另外，团队肯定需要就软件的状态进行沟通。 i青想像一下如果您可以按一个键就完成这些过程。本书向您展示了如何创建一个虚拟的集成按钮，将许多软件开发过程都自动化。而且，我们介绍了如何持续地按下这个按钮，从而减少创建可部署的应用程序时的风

险，如较晚才发现缺陆，低品质的代码等。在创建CI 系统时，许多过程都被自动化，在每次修改开发的软件时，都执行这些过程。 IX 什集成软件的过程不是新问题。在一个人开发的项目中，依赖外部系统又比较少的话，软件集成不会成为太大的问题，但是随着项目复杂度的增加(即使只增加一个人) , 就会对集成和确保软件组件能够一起工作提出更多的要求一一要早集成，常集成。等到项目快结束时才来集成会导致各种各样的软件品质问题，解决这些问题代价很大，常常会导致项目延期。 CI以较小增量的方式迅速地解决这些风险。在Martin Fowler热门的文章 ((Continuous Integration)} (持续集成)。中，他将CI 描述为: • ·一种软件开发实践，即因队的成员经常集成他们的工作，通常每个成员每天至少集成一次一一这导致每天发生多次集成。每次集成都通过自动化的构建(包括测试)来验证，从而尽快地检测出集成错误。许多团队发现这个过程会大大减少集成问题，让团队能够更快地开发内聚的软件。根据我的经验，这意味着: ·所有开发者都先要在他们自己的工作站上执行私有构建@，然后再将他们的代码提交到版本控制库中，从而确保他们的变更不会导致集成构建失败。 ·开发者每天至少向版本控制库提交一次代码。 ·集成构建每天在一台独立的计算机上进行多次。 .每次构建都必须 100%通过测试。 ·生成可以进行功能测试的产品(如WAR 、配件、可执行程序等)。 .修复失败的构建是优先级最高的事情。 ·某些开发者复查构建生成的报告，如编码标准报告和依赖分析报告，寻找可以改进的地方。本书讨论了 CI 中自动化的方面，因为您会从自动化重复的、容易出错的过程中得 e 参见 www.martinfowler.com/articles/continuouslntegration .html 0 @ 私有(系统)构建和集成构建模式在Stephen P. 8erczuk和8rad Appleton写的 ({Software Configuration Management Pattems)) 一书中有介绍。

X 到许多好处。但是，正如Fowler所指出的， CI就是经常集成工作的过程，这不一定需要自动化的过程。我们相信，既然已经有许多工具让CI成为自动化的过程，那么使用 CI服务器来自动化CI实践就是一种有效的方式。不管怎样，也许手工集成的方式(利用自动化的构建)很适合您的团队。快速反馈持续集成增加了您获得反馈信息的机会。这样，您每天都能多次了解项目的状态。 CI可以用来减少引入缺陷和修复缺陷之间的时间，从而改进总体软件品质。开发团队不应该相信因为 CI 系统自动化了，就可以避免集成问题。如果团队只使用自动化的工具来编译源代码，就更是如此。有些人把编译称为"构建"，实际上不是的(参见第 1 章)。有效的CI实践包含的东西比工具多得多。它包括本书中介绍的实践，如经常向版本控制库提交代码，立即修复失败的构建以及使用独立的集成构建计算机等。 CI的实践支持快速反馈。如果应用了有效的 CI实践，您可以每天多次了解到正在开发的软件的健康状况。而且， CI与重构、测试驱动开发等实践配合得挺好，因为这些实践的中心思想都是进行小的变更。从本质上来说， CI提供了一张安全网，确保变更能够与软件的其他部分一起工作。从更高的层面上讲， CI增加了团队整体的信心，减少了项目所需的人工，因为它通常是一个无人执守的过程，在软件发生变更时执行。关于"持续"的注释我们在本书中使用"持续"这个术语，但是这种用法从技术上来说是不对的。 "持续"意味着某事一旦启动就不会停止。这意味着集成过程一直在执行，但是即使对于最密集的 CI环境来说，也不是这样的。所以，我们在这本书中讲述的吏像是"经常集成"。谁应该读这本书在我的经验中，把软件开发当成工作的人和把它当成职业的人之间有着显著的差别。本书是为那些把软件开发当成职业，并发现自己在做一些重复的过程的人而写的 (或者我们将帮助您意识到您正频繁地这样做)。我们描述CI的实践和好处，让您知道如何应用这些实践，这样您就可以将时间和专业知识用在更重要、更有挑战性的问题

分享到：

赞收藏

资料库

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

相关推荐

开发技术

热门标签

最新资料