芏唷ug 在项目的早期就存在，到最后集成的时候才发现问题，我们测试人员需要在集成阶段帮助开发人员花费大量的时间来寻找Bug 的根源，加上软件的复杂性，问题的根源很难定位，甚至出现不得不调整底层架构的情况！”
“是啊，所以好多团队在这个阶段的除虫会议（Bug Meeting）特别多，会议的内容基本上都是讨论Bug 是怎么产生的，最后往往发展为不同模块的负责人互相推诿责任。”
“通过持续集成，可以有效地解决这个问题。”
“具体该怎么做呢？”阿捷拿起笔，准备记录。
“你看我们的开发、测试流程：当任何一个人修改代码后，首先运行单元测试；通过后，提交代码；构建产品；把它放在模拟的产品运行环境下，进行测试；遇到问题，进行修正并重复上述过程。我们需要首先让上述过程自动化。”
“嗯，这样肯定可以大幅提高开发测试效率。”阿捷表示赞同，并示意她继续讲下去。 txt小说上传分享
第10章 持续集成（3）
“我觉得需要做这样几件事情：编译自动化、单元测试自动化，再加上自动打安装包、自动部署到测试环境，并进行功能测试、性能测试！”
“我觉得还有必要加上一条，自动统计测试结果，并通过邮件发送给相关的人。有了这样的一个框架，你们测试人员就可以从一些烦琐的手工工作中解放出来，做真正有意义的事情了。”
“嗯，有道理。”
“看来关键是如何实现完全的自动化，从读取源代码、编译、连接、测试，整个创建过程都应该自动完成。对于一次成功的创建，我们要做到在这个自动化过程中的每一步都不能出错。”
“这么一来，也就不需要专人做Build Manager了！我总算解放了 。”阿朱对这个想法的实施，肯定已经神往很久了。
“嗯，具体的工作是不需要你亲自动手了，但是策略性的东西，还得你把关。譬如软件配置管理（SCM）、分支/合并策略、软件发布通知（Release Notes）等。”
“这些工作不需要经常做的。我会搞好的。”阿朱笑着说。
“不过，上述所说的持续集成过程，实际上要求开发过程也要有对应的改变，譬如自动单元测试那块，应该由开发人员负责。”
“对，因为这不再是传统的编译和连接那么简单，属于自测试的范畴。自测试的代码是开发人员提交源码的时候同时提交的，是针对源码的单元测试，将所有的这些自测试代码整合到一起形成测试集，在所有的最新的源码通过编译和连接之后，还必须通过这个测试集的测试，才能算是一次成功的创建。”
“这好像就是McConnell 提出的‘冒烟测试’吧。”阿捷突然想起了前几天看过的一篇文章。
“对！这种测试的主要目的是为了验证创建的正确性。在持续集成里面，这叫做集成验收测试——Build Verify Test，简称 BVT。我们测试人员按理不会感受到 BVT 的存在，我们只针对成功的创建进行测试，如功能测试。”
“嗯，这块我会跟大民、小宝他们说的，让他们去实现。”
“那我和阿紫负责其他部分的测试框架。”
“我还有一个问题，持续集成和日创建有什么关系？二者是不是就是一个东西？”阿捷绝对不会放过任何一个学习的机会。
“有些不同。
持续集成强调了集成频率，和日创建相比，持续集成显得更加频繁，目前业界推荐的最佳实践是每一个小时就集成一次。
持续集成强调及时反馈，日创建的目的是得到一个可以使用的稳定的发布版本，而持续集成强调的是集成失败之后向开发人员提供快速的反馈，当然成功创建的结果也是得到稳定的版本。
日创建并没有强调开发人员提交（check in）源码的频率，而持续集成鼓励并支持开发人员尽快提交对源码的修改并得到尽快的反馈。
“噢，重点就是‘频率’和‘反馈’两个方面。”阿捷若有所思。
“对！持续集成有一个与直觉相悖的基本要点，那就是‘经常性的集成比偶尔集成要好’。对于持续集成来说，集成越频繁，效果越好 ，如果集成不是经常进行的，少于每天一次，那么再集成就是一件痛苦的事情，也就是我们过去及现在一直遇到的问题。”
“我想，创建一个持续集成的环境技术上是比较复杂的，也需要一定的时间，但长期回报肯定是巨大的。”阿捷带着问询的眼光瞅着阿朱。
“没错！只要我们能够让持续集成可以‘及时’抓到足够多的Bug，从根本上消除传统模式的弊端，这就已经很值得为它所花费的开销了。”阿朱非常期望这件工作马上开工：“那我们需要赶紧开一个会议，大家统一一下认识，做一个分工，然后分步实施。”书包 网 。 想看书来
第10章 持续集成（4）
“嗯，很好的建议！这个任务我就交给你了，怎么样？”
“没问题！我很乐意做这样的事情。”
二人又随便聊了聊，讨论了一些其他事情。
这次“One to One”的结果来看，还是非常成功的，持续集成这个想法如果得到实施，那将是一次巨大突破，阿捷决定把这个思想记录到自己的Blog上。
在他人眼里，像阿捷这样高学历、高薪水，出入高档写字楼的白领单身人士，身边一定会有很多女孩子。其实阿捷的生活完全不是别人想象的那样。虽然不知道自己还有多久能告别单身生活，可是阿捷并不着急。因为他一直崇尚这样一句话，“宁愿高傲地发霉，也不要委屈地谈恋爱”，忘记这是谁的QQ留言了，但享受生活的阿Q式精神是必不可少的，要在平淡的生活中用自己的生活方式来享受人生，去品尝大千美食，去饱览世间万象。故而，阿捷的业余生活非常丰富，不仅经常去北师大踢踢野球，顺路饱饱眼福，他还是“绿野”的会员，从“香巴拉”拉练到灵山黄草梁穿越，北京周边都留下了阿捷的足迹。
周末，对于阿捷这种光光人士来说，既好过，又不好过。 好过的是孤家寡人，想做什么就做什么，非常自由。不好过的是偶尔感觉到一点孤独，特别当自己的狐朋狗友抛开自己，跟女朋友出去约会的时候，只有忠实的小黑安静地趴在自己的腿边，陪着阿捷打CS。
自从阿捷接触敏捷开发，阿捷的周末生活已经慢慢有了些变化，从原来的遛完小黑就开始无聊地打CS，到每天都泡在网上如饥似渴地学习Scrum。而敏捷圣贤的出现，则让阿捷多了一份期待。那种似师似友的感觉很奇妙，敏捷圣贤可以在全球各地Tr*el更让喜爱旅行的阿捷羡慕不已。这天在网上，阿捷又遇见正在德国做Consultant的敏捷圣贤。
阿捷：Hi，你好！圣贤，德国玩得怎么样？现在在哪儿呢？
敏捷圣贤：嘿，哪有你说得那么轻松，我这可是工作的一部分。我现在在慕尼黑。
阿捷：不错！我喜欢那个城市，因为有德甲最伟大的球队——拜仁慕尼黑。
敏捷圣贤：你喜欢哪个球星？
阿捷：当然是小猪了！”
敏捷圣贤：施魏因斯泰格？我可以帮你带一件他签名的球衣！
阿捷：真的？
敏捷圣贤：真的！
阿捷：我都不知道怎么感谢你好了！
敏捷圣贤：不用这么客气呀，举手之劳的。
阿捷：嗯，对你可能是，但对我却不是……无论如何，我要好好感谢你才对，不仅在这件事情上，你在项目管理上对我的帮助，也使我受益匪浅。
敏捷圣贤：其实，我从你们的实践中也获得了很多值得思考的东西。对了，最近你们怎么样？有没有试验一下其他敏捷实践？
阿捷：持续集成CI（Continue Integration）。
敏捷圣贤：这是一个非常好非常有用的XP实践！它可以非常有效地降低风险，但是它对与编程相关的日常活动提出了很高的要求。你们现在做到什么程度了？
阿捷：才刚刚开始！有什么需要注意的吗？
敏捷圣贤：哦，我以前的团队实行持续集成时，遇到了很多问题。在后来，我遇到Paul Duvall博士，才知道我们错误地采用了一些持续集成的反模式。
阿捷：Paul Duvall？反模式？
敏捷圣贤：Paul Duvall是 Stelligent Incorporated 的 CTO，该公司是一家咨询公司，在帮助开发团队优化 Agile 软件产品方面被认为是同行中的翘楚。反模式（anti…pattern）这个词，表示在特定环境中不应该采用的做法。反模式最终可能产生严重影响。 txt小说上传分享
第10章 持续集成（5）
阿捷：看来是一位大师啊！都有哪些做法是反模式？这对于我们这样一个缺少持续集成经验的团队，应该是非常有帮助的。
敏捷圣贤：他主要讲到了六个反模式：第一个是代码提交不够频繁，导致集成延迟。也就是说，如果代码长期留在开发人员自己手中，没有及时提交，如果其他人对系统的其他部分做出修改，而修改可能会相互影响的话，集成就会延迟；延迟越长，消除其严重影响就越困难。
阿捷：那看来必须要求开发人员每天提交一次。
敏捷圣贤：对。把任务划分得越小，越容易完成，开发人员才能越容易地经常性提交。第二个反模式是经常性构建失败，使团队无法进行其他任务。
阿捷：嗯，这个问题对我们影响比较小！我们在将代码提交到存储库之前，先从存储库中更新代码，再运行私有构建（Private Build），保证构建成功后，才能提交。万一构建失败，会专门指定开发人员并以最高优先级尽快修复。
敏捷圣贤：你们做得不错！第三个反模式是构建反馈太少或太迟，使开发人员不能及时采取纠正措施。我想你们也应该问题不大。
阿捷：对，我们对每次构建结果