如何快速捕获.NET代码Bug

团队开发的一个方面就是在将所有的改动合并到中心资料库之前，允许单独的开发者在本地编写并构建（build）有特色的代码。开发者可以在本地测试与调试最新的版本，并且可以保证他们所有的工作代码可以与其他同事的协同工作，他们可以手动测试这些代码，但是更好的办法就是将这一过程自动化并且提供即时反馈，其中一个非常优秀的解决方案就是持续集成。

持续集成
对于应用软件开发团队而言，有很多提高产品质量和效率的思想，其中的一种思想就是被称作持续集成的方法，持续集成的一个前提就是即时反馈。持续集成的一种最简单的形式就是由一个开发者完成所有的工作，因为所有的改变都是立即可见的，因此，单个开发者在他们出现问题的时候就能知道这个问题的存在，当同样的方法应用到团队环境中，实时方式就会成为一个问题。

持续集成最大的特色在于当开发者提交他们工作的时候 ,可以减少其他开发者用于检测bug的时间，而往往非常难以追踪到由这些bug所导致的问题的根源，因为问题通常是由于集成了新的代码所致，因集成而出现的bug可能在出现问题之前已经被嵌入到代码中很久了，与其花费时间去追踪这些bug还不如花在别的项目上，关键是要尽早地发现问题。

在持续集成方法的帮助下，绝大部分bug可以在引入代码的时候被发现，因为这些“嫌疑犯”（开发者的代码）是在他们提交新代码之后才出现了错误，所以更加明显。因此，少花些时间在追踪这些错误上，开发者就能有更多的时间解决他们自己的问题，最终的结果是生产效率的提高，但这种方法也依赖于构建新版本的频率，从而向开发人员提供有价值的反馈。

何时进行构建（build）？
我还记得多年前曾工作过的项目，进行一次构建需要大量的时间和精力，要提醒开发人员递交他们的代码，而且手动的构建过程非常紧张，很自然的，当对开发团队的代码进行构建的时候，错误就摇头摆尾地出现了，追踪这些问题是需要时间的，并且希望能沿着正确的方向去解决问题，这样才能获得成功，而这一过程所需的时间往往导致了构建次数的减少，但是，多次构建更易于从持续集成中受益。

如果您想知道一个成功构建的条件是什么，答案视乎您的项目和环境而决定，但是我经常将它定义为所有的源文件都成功编译、部署并且一系列测试都在系统中获得成功，您需要一系列工具来实现这些工作，虽然自动测试（automated testing）并不是必需的，但是我强烈推荐这种方法。

工具
以下是在.NET环境中建立与运行持续集成方法所必需的几本工具列表：

注意：安装与设置这些工具的内容已经超出了这篇文章的范围，但是每个产品的网络社区所提供的文档中包含了您使用这些产品所需的信息。

您准备好使用持续集成了么？
持续集成并不是针对缺陷代码的灵丹妙药，但它绝对可以释放出您宝贵的时间去应付更紧张的问题，开发人员依然需要编写强壮的代码并进行良好的单元测试，另外，代码应该按照规则进行提交（我建议每日提交），然而，使用持续集成可以帮助您验证代码、测试、设计等的质量，持续集成能帮助您节省出原本用于构建的时间，但您需要一些时间去设置和管理专门用于持续集成的服务器。