构建自动化驶向何方?

　　时下大多数开发人员对持续集成(Continuous Integration，CI)的基本原理已经很熟悉，但是他们中只有一小部分人能够从优化CI设置中彻底受益。毫无疑问，一个有效的持续集成环境可以帮助你的团队节省时间、金钱甚至减少存有的顾虑。通过持续集成，我们可以更早地发现bug，更轻松地找出导致其发生的原因并最终有效地解决。持续集成可以更好地管理源代码，更有效地使用自动化分析工具，鼓励编写好的测试，跟踪进度以及突破开发人员活动中的瓶颈。持续集成可以让部署过程更简单且发布过程更加平稳和可靠。借助于CI，管理者可以得到更多的图表，了解到更多的信息，而开发者可以专注于开发而不用过多交流，也就更加高兴。换句话说，如果不使用持续集成，那么就好比用记事本编写代码来开发软件，虽然可行，但是太低效了。

　　在本文中，来自Wakaleo咨询公司的首席咨询师John Smart，将给我们介绍如何把持续集成由一个名义上的定时作业，变为开发活动中一个有效、而且能提高生产力的“中枢”。

　　持续沟通流

　　一个良好的敏捷开发环境本质特征就是尽可能的最大化小组成员间的信息流。每一个开发人员都需要尽快地知道何时构建过程失败，或者何处改动可能会对应用程序质量造成不良影响。如果构建过程失败了，那么首要工作就是要知道做了什么改动，以及为什么做这些改动：所有的这些信息都应当在开发人员敲击几下键盘后就能通过最直接的方式获得。

　　即便是最基本的CI设置，它也会在构建失败后给开发人员发送电子邮件。其实我们只需要下一点点功夫，就能比现在做得更好。一个良好设置的持续集成服务器应该像团队沟通中的中枢一样工作。除了简单地发送电子邮件进行提醒外，其实还有很多事情可以做，例如现代CI工具中的许多特性——这些特性可以更平稳、更有效地向开发人员反映代码改动和构建失败的情况。

　　电子邮件大概是CI提醒方式中最古老也是最常使用的方式了，只是因为它非常普遍而且易于建立。尽管如此，事实上电子邮件是一个相对低效的提醒机制。当构建过程失败时，你希望被尽快地通知到，越快越好。如果因为电子邮箱客户端的更新而等上15分钟的话，那么可能就浪费掉了开发时间。除此之外，电子邮件通常很容易让开发人员分心。在企业里，每天的非紧急的或是不重要的电子邮件都会有很多。事实上许多优秀的开发人员都禁用电子邮件提示，只是在一天中定时地去检查几次邮件。

　　即时消息相对而言则是一个更加合适的提醒方式，有好几个原因。最重要的原因是，即时消息是(几乎是)即时的。你不再需要因为电子邮件客户端在服务器中检查新邮件而等上10分钟，使用即时消息，你能被立即通知到。它比电子邮件更加方便，而且阅读起来也更快。不仅如此，来自构建服务器的IM消息也会得到相关的重视，而不会淹没在大量无用的其它信息中。

　　当事件发生后，使用快速即时信息和花上10到15分钟使用电子邮件也许只相差几分钟，但千万不要低估这几分钟的重要性。那几分钟足够让一个开发人员丢失重点，并转移到其它的一些事情上，结果就导致了开发人员很难回到上下文中去修复问题。

　　使用即时消息的另外一个好处在于它可以扩展到桌面以外的应用。像BeeJive这样的应用程序可以将即时消息用到移动设备诸如Blackberries(黑莓)和iPhones上。这样的话，即使开发人员不在办公室，也能收到至关重要的构建失败提醒。

　　即时消息提醒比起电子邮件，可以更多的与CI服务器进行交互。作为一个沟通的中介，即时消息要比电子邮件更加的自然，它还可以进行比 Subversion 提交信息还要多的交互。通过利用即时消息，如今的一些CI工具不仅仅可以发送提醒，还可以让开发人员更轻松地与构建服务器以及其他组员进行交互与交流。

　　当然，即时消息不是仅有的另一种可用提醒方式。如果想让大家注意到构建信息的话，最好采用一种能够融入相应企业文化的提醒机制。例如，一些公司使用社交网 络的工具例如Twitter，作为一个有效的内部交流渠道。对于这些组织而言，使用Twitter也可以算是一种有效的构建提示方法了。

　　保持构建过程高效率

　　持续集成环境的一个首要目标是要保证开发过程的顺利进行，并且避免由集成问题带来的障碍和开发延期。当集成问题突然出现时，开发人员应当有义务尽快的去提交一些代码来解决这个问题，以避免影响到其他开发人员。如果没有持续集成环境，开发人员通常会在集成问题上卡住而找不到一个解决方案(“嘿，它在我的机器上能运行啊!”)。

　　想让开发过程一直保持最好的状态，那么团队成员(尤其是团队领头人，流程专家等)需要能够监测构建过程，这样他们可以识别定位出日常生活里降低开发人员效率的问题。其中最好的方法就是去了解如何最好地使用构建感测。

　　构建感测是一个用在持续集成周期中，用以描述构建长期统计数据的术语。Bamboo，一个不错的CI工具，它就提供了很高级的构建特性。构建感测为你提供了关于构建要花多久，是否成功，以及解决这个构建失败问题要花多久等等之类的信息。这些数据很重要，因为它可以让你知道构建过程长期以来是什么样的。正是这种数据，而不是单个构建的结果，可以帮助你最终优化构建过程。

　　一定数量和频率的构建失败一直是一个不错的着手点。隔离的构建失败通常不需要担心——你需要做的是去检查一系列反复出现的构建失败。当一个构建反复失败时，也许是因为开发人员正纠结于一段非常麻烦的代码，或者是团队人员没注意到。虽然这两问题的原因不一样，并且解决的方法也不一样，但是它们都应当被进一步地调查。

　　通过深入分析测试结果，你可以了解到更多关于为什么构建会失败的信息。许多现代的CI工具都可以让你研究长期的测试行为，例如，把一直经常失败的、或者要花很长时间进行解决的测试跟其他测试隔离开来。如果同样的测试不断失败的话，这就意味着有什么地方过于复杂或者代码过于脆弱，这种情况下可以做一些重构。除此之外，这些工具还能让你知道测试运行了多久，这是另一类问题发生的源头。

　　事实上，构建失败不是唯一减慢开发进程的原因。缓慢的构建过程是另一个罪魁祸首。

　　导致构建过程缓慢的最常见的原因是结构混乱的测试套件。经验丰富的Java开发人员常常会将单元测试与集成测试分开来。虽然两者区别大差不差，但是一般来说，单元测试是相对孤立的、较小的、快速的、轻量级的测试类。它们主要是用来确保类能够独立地正常工作。而另一方面，集成测试则较为缓慢，需要更长的运行时间，并且可能会访问外部的资源如测试数据库，或者加载复杂的配置文件。它们被用来测试应用程序中的不同模块和类如何共同工作。性能测试和集成测试差不多，但是两者的目标有所不同。

原文转自：http://www.ltesting.net