摘要： 正式进入持续集成的系列介绍持续集成 (CI) 是什么？引用Martin Fowler的描述，持续集成是一种开发实践，即团队的成员经常集成他们的工作，通常每个成员每天至少集成一次---这导致每天发生多次集成。每次集成都通过自动化的构建 (包括测试)来验证，从而尽快的检测出集成错误。谁应该关注持续集成？软件工程所有关系人都应该关注持续集成。对于开发人员，CI可以让你把更多的精力花在做好软件上，而不是每天浪费大量时间解决一些集成过程中产生的问题。对于测试人员，CI可以保持测试一直持续稳定的进行，让你更加有效、合理的展开工作。避免出现有时候一天要测试好多版本，有时候连着几天没有版本可测的情况。对于数据 阅读全文

摘要： 上一篇说了一堆废话，现在正式进入持续集成概念的推广。我们的目标是：通过持续集成，让所有软件项目的参与方都很容易，甚至是被迫的清楚当前项目的持续集成情况。第一步，让所有人产生共鸣，下面描述几个场景，大家看看是否似曾相识：场景1：开发人员A更新代码，发现本地编译报错，开始询问同一开发组的成员。这时有些人继续埋头继续开发，有些人在编译自己本地的代码，发现没问题。于是A只能自己查看出错地方的SVN Log，发现是开发人员B漏提交了一个文件。通知B，B检查了代码，确实是漏提交了，但是本地已经修改了其他代码，并且添加了一些别的文件，暂时不能提交。于是B跟A说：“我现在不能提交，你先等一下，要不就把那段代码 阅读全文

摘要： 出于对产品质量、开发效率的考虑，公司要在日常的开发过程中引入持续集成。持续集成这个概念其实很多人都应该很熟悉，或者接触过很久。其实公司以前也做了很多这方面的工作，但是一直存在着一些问题。就是很多人对其抱着无所谓的态度，每天定时的将代码代码提交到trunk，让服务器去整一些事情，然后立马关电脑下班，出了问题明天再说。更有甚者，对其抱有抵触的情绪，觉得浪费了很多时间，不如好好多写几行代码，改几个bug。当然了，也有人支持，但是认为持续集成就是编译，保证提交的代码能够通过MSBuild的编译，或者在出错的时候收到一封邮件，及时修正一下提交的错误就OK了。其实这些想法也不是没有道理，早些年，在没有持续 阅读全文