构建自动化驶向何方?

　　构建自动化驶向何方?软件测试

　　时下大多数开发人员对持续集成(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也可以算是一种有效的构建提示方法了。

　　保持构建过程高效率

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

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

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