.Net下的开源持续集成

谈到持续集成,不如先谈谈集成。软件开发中的集成,通俗地讲就是把各个相关部分的东西组合起来,形成一个可用的软件。比如一个软件项目由几个小组来负责完成,每个小组负责其中一部分功能的实现,比较典型的是在现在的网络游戏开发中,通常有负责引擎的小组,负责游戏逻辑的小组,负责美工的小组,这些小组开发出的东西必须结合在一起才能形成一个可用的游戏;而每个小组内部的每个成员,他们每天在写着不同部分的代码,这些开发人员必须将各自的成果组合起来,才能完成他们共同的目标。从这个意义上讲,从每天每个开发者的日常开发,到各个软件模块的组合拼接,软件集成无所不在,一个完整可用的软件,就是通过不断地集成每个开发人员的代码而形成的。

每个开发过软件的人都能体会到,软件开发绝非一帆风顺,每个人开发出来的代码绝对不会魔术般的自己组合在一起,当新的功能加入到原有软件中的时候,往往不小心破坏了原有的功能,引入了一些bug,当老的bug被修复的时候,又往往会导致其他bug的产生,更糟糕的是,这些bug往往在当时并不能及时被发现。当小组成员们完成了自己所负责的模块,等到最后来一起集成的时候,他们可能已经做好了修复集成问题的心理准备。所有的这一切,都是每个开发人员的切肤之痛。那么,问题到底出在哪了?

让我们不妨换一种思维,让我们不要停留在如何地去修复bug和集成过程中产生的问题,我们渴望的理想状况是,每当我们开发出新的代码并将他们加入原系统中的时候,如果我们能够被及时告知我们是否破坏了原有系统的功能,那么我就能够及时的作出反应,修复这些部分。如果这个过程的粒度足够的细、足够地频繁,我们就能期望每次新功能引入的时候所引起的破坏足够小,并且修复起来足够简单,如果每个开发人员都能够享受到如此的方便并且保证新加入的功能不会影响原有的功能,我们的整个软件过程就能够以一个稳步可靠的步伐,持续增量的向前行进,而不是不断地加入新的代码,然后等到后来bug被人发现的时候被动地去修复它。我想稳步可靠、持续增量的软件过程,是我们每个开发者心目中的理想过程。从开发者的角度来看,毕竟谁也不想经历那种当发现自己的修改破坏的原有的功能的时候的恼火的感受。

持续集成通俗地说就是持续地、频繁地进行集成,每当有新的修改加入的时候,修改的作者能够被及时地告知他的修改是否在引入新的功能的同时保证原有功能的完整。如果整个软件开发团队在一开始就采用这种方式,我们的软件就能被稳步可靠的构建起来。

你也许会有疑问:“你说的只是一种理想状况罢了,谁都希望自己在加入新的代码的时候得知自己的代码是否破坏了原有的功能,但是怎么能够做到这一点,谁有能力来及时地告诉我们哪里有问题?持续集成这个想法不错,但怎么样能够做到持续集成?”我想这些问题是非常好也是关键的问题,持续集成究竟是否可行,如果可行,又该如何执行?我们这里不妨来整理一下,看看究竟什么是持续集成的难点。持续集成的难点主要在于,在新的功能加入的时候,如何来判断整个系统功能仍然完整;出错或者成功,谁来告诉我,如何告诉我;当大家一起协作的时候,如何保证每个人都能够准确地被告知而不会发生混乱。让我们来一个个地分析这些问题。

首先,确保真个系统功能完整性的手段就是测试,如果我们对所有的功能都有完整的测试,那么当新的功能引入的时候,如果某些原有的测试失败,就说明新的修改破坏了原有的功能,而失败的测试就能准确地告诉我们新的修改破坏了哪些原有的功能。其次,持续集成工具将告诉我们集成是否成功,持续集成工具通过运行整个系统中的测试,根据测试的结果来通知开发者,哪些测试失败导致的集成失败。每个软件项目通常会使用版本控制工具例如SVN、CVS,每当有开发者将新的修改加入到系统的代码库中时,持续集成工具会check out出代码库中的最新版本,使用自动化的构建工具例如Ant、Rake等,自动地编译项目中的代码、部署整个应用、准备测试所需的环境和数据、运行所有的测试包括单元测试、功能测试、集成测试等,在整个过程结束后将结果报告出来,持续集成工具会指出任何一个过程中出现的错误,并且准确地报告给开发者。在多人协作的情况下,版本控制工具确保了每个开发者的修改被正确有序地保存,当每个开发者想要提交自己的修改的之前,必须首先确保上一个人所提交的修改被成功集成,才能提交自己的代码,当确保自己的代码被正确集成之后,自己的工作才算完成,否则,就必须修复错误,再次提交,如此反复,直到被成功集成。

开源社区已经为我们提供了非常优秀的持续集成工具,CruiseControl、CruiseControl .Net已成为广泛使用而且非常成熟的持续集成工具,而持续集成所需要的自动化构建工具和版本管理工具如Ant、NAnt、SVN也已经是非常成熟。在下面,我尝试在我的使用经验的感受的基础上,挑选一些比较成熟或者很有潜力的工具,结合自己的使用经验,给大家做一些介绍。 Continue reading “.Net下的开源持续集成”

服务器发送了意外的返回值(405 Method Not Allowed),在响应“MKCOL”的请求

刚刚在通过TortoiseSVN客户端往SVN Server提交数据的时候,出现了以下错误:
服务器发送了意外的返回值(405 Method Not Allowed),在响应 “MKCOL” 的请求
解释一下现场发生之前我的操作:
我删除了一个文件夹后又创建了一个同名文件夹,在删除文件夹时未进行提交
解决方法:
删除出现错误的文件夹
SVN Update
这时服务器上存在的文件夹会出现在本地
删除原有的文件夹
SVN Commit
重新创建文件夹
SVN Commit
OK!