.Net下的开源持续集成

谈到持续集成,不如先谈谈集成。软件开发中的集成,通俗地讲就是把各个相关部分的东西组合起来,形成一个可用的软件。比如一个软件项目由几个小组来负责完成,每个小组负责其中一部分功能的实现,比较典型的是在现在的网络游戏开发中,通常有负责引擎的小组,负责游戏逻辑的小组,负责美工的小组,这些小组开发出的东西必须结合在一起才能形成一个可用的游戏;而每个小组内部的每个成员,他们每天在写着不同部分的代码,这些开发人员必须将各自的成果组合起来,才能完成他们共同的目标。从这个意义上讲,从每天每个开发者的日常开发,到各个软件模块的组合拼接,软件集成无所不在,一个完整可用的软件,就是通过不断地集成每个开发人员的代码而形成的。 每个开发过软件的人都能体会到,软件开发绝非一帆风顺,每个人开发出来的代码绝对不会魔术般的自己组合在一起,当新的功能加入到原有软件中的时候,往往不小心破坏了原有的功能,引入了一些bug,当老的bug被修复的时候,又往往会导致其他bug的产生,更糟糕的是,这些bug往往在当时并不能及时被发现。当小组成员们完成了自己所负责的模块,等到最后来一起集成的时候,他们可能已经做好了修复集成问题的心理准备。所有的这一切,都是每个开发人员的切肤之痛。那么,问题到底出在哪了? 让我们不妨换一种思维,让我们不要停留在如何地去修复bug和集成过程中产生的问题,我们渴望的理想状况是,每当我们开发出新的代码并将他们加入原系统中的时候,如果我们能够被及时告知我们是否破坏了原有系统的功能,那么我就能够及时的作出反应,修复这些部分。如果这个过程的粒度足够的细、足够地频繁,我们就能期望每次新功能引入的时候所引起的破坏足够小,并且修复起来足够简单,如果每个开发人员都能够享受到如此的方便并且保证新加入的功能不会影响原有的功能,我们的整个软件过程就能够以一个稳步可靠的步伐,持续增量的向前行进,而不是不断地加入新的代码,然后等到后来bug被人发现的时候被动地去修复它。我想稳步可靠、持续增量的软件过程,是我们每个开发者心目中的理想过程。从开发者的角度来看,毕竟谁也不想经历那种当发现自己的修改破坏的原有的功能的时候的恼火的感受。 持续集成通俗地说就是持续地、频繁地进行集成,每当有新的修改加入的时候,修改的作者能够被及时地告知他的修改是否在引入新的功能的同时保证原有功能的完整。如果整个软件开发团队在一开始就采用这种方式,我们的软件就能被稳步可靠的构建起来。 你也许会有疑问:“你说的只是一种理想状况罢了,谁都希望自己在加入新的代码的时候得知自己的代码是否破坏了原有的功能,但是怎么能够做到这一点,谁有能力来及时地告诉我们哪里有问题?持续集成这个想法不错,但怎么样能够做到持续集成?”我想这些问题是非常好也是关键的问题,持续集成究竟是否可行,如果可行,又该如何执行?我们这里不妨来整理一下,看看究竟什么是持续集成的难点。持续集成的难点主要在于,在新的功能加入的时候,如何来判断整个系统功能仍然完整;出错或者成功,谁来告诉我,如何告诉我;当大家一起协作的时候,如何保证每个人都能够准确地被告知而不会发生混乱。让我们来一个个地分析这些问题。 首先,确保真个系统功能完整性的手段就是测试,如果我们对所有的功能都有完整的测试,那么当新的功能引入的时候,如果某些原有的测试失败,就说明新的修改破坏了原有的功能,而失败的测试就能准确地告诉我们新的修改破坏了哪些原有的功能。其次,持续集成工具将告诉我们集成是否成功,持续集成工具通过运行整个系统中的测试,根据测试的结果来通知开发者,哪些测试失败导致的集成失败。每个软件项目通常会使用版本控制工具例如SVN、CVS,每当有开发者将新的修改加入到系统的代码库中时,持续集成工具会check out出代码库中的最新版本,使用自动化的构建工具例如Ant、Rake等,自动地编译项目中的代码、部署整个应用、准备测试所需的环境和数据、运行所有的测试包括单元测试、功能测试、集成测试等,在整个过程结束后将结果报告出来,持续集成工具会指出任何一个过程中出现的错误,并且准确地报告给开发者。在多人协作的情况下,版本控制工具确保了每个开发者的修改被正确有序地保存,当每个开发者想要提交自己的修改的之前,必须首先确保上一个人所提交的修改被成功集成,才能提交自己的代码,当确保自己的代码被正确集成之后,自己的工作才算完成,否则,就必须修复错误,再次提交,如此反复,直到被成功集成。 开源社区已经为我们提供了非常优秀的持续集成工具,CruiseControl、CruiseControl .Net已成为广泛使用而且非常成熟的持续集成工具,而持续集成所需要的自动化构建工具和版本管理工具如Ant、NAnt、SVN也已经是非常成熟。在下面,我尝试在我的使用经验的感受的基础上,挑选一些比较成熟或者很有潜力的工具,结合自己的使用经验,给大家做一些介绍。

Windows7 & 8 “用户文件夹”更改位置(更改Users目录位置)

Windows 7和Windows 8的用户文件夹默认所在位置是系统盘(通常是C盘)下的“\Users”目录之内。该文件夹中储存着所有的用户生成文件,比如你保存在“桌面”上的文件(实际上是保存在C:\Users\YourUserName\Desktop目录之中),再比如你保存在“我的文档”里的文件(实际上是保存在C:\Users\UserName\Documents目录之中)。 而随着Windows里安装的软件越来越多,就会有越来越多的“用户生成文件”被保存在“用户文件夹”里。在资源管理器的地址栏里输入“%AppData%”之后回车,就可以看到有多少软件把用户生成数据保存在那里。 用户文件夹处于系统盘的坏处在于,如若系统盘一旦坏掉,就可能连带用户文件一并丢失;其次,由于(随着使用不断生成的)用户文件处于系统盘,也没办法时常备份“干净的系统盘”。 如果能把用户文件夹挪到另外一块儿硬盘上(或者另外一个硬盘分区上),那么系统维护就会容易得多。平时生成的文件(大多数人放在“桌面”、“我的文档”里的文件最多),都被保存在系统盘(或分区)之外;于是随时都可以在不必担心用户文件丢失的情况下重新安装系统(或恢复系统备份)。 注意,以下假设你想把用户文件夹设置在D盘,假定D盘是NTFS分区。 在安装Windows7或者8的过程中,要求输入用户名及密码的时候,先不如输入任何信息,按“Shift+F10”呼出DOS窗口,输入以下命令: robocopy “C:\Users” “D:\Users” /E /COPYALL /XJ rmdir “C:\Users” /S /Q mklink /J “C:\Users” “D:\Users” 而后关闭DOS窗口,按部就班继续安装直至完成。 如此安装的Windows7,所有“用户特殊文件夹”(User Special Folder)的内容都已经被设置在D盘(非系统盘)上。 如果想要移动已安装好的Windows7或者8中的用户文件夹,那么就要按以下步骤操作(稍微麻烦一点,并且过程中可能会出现无法拷贝文件的情况): 关闭所有应用程序; 按一下“Windows”键,输入“compmgmt.msc”之后按“Enter”,呼出“计算机管理器”; 鼠标点击“Administrator”,选择属性,而后在随后的对话框中去掉“帐户已禁用”之前的勾,而后关闭“计算机管理器”; 注销当前用户(注意,不是“切换用户”),而后以“Administrator”登录 打开命令行窗口,输入以下命令:robocopy “C:\Users” “D:\Users” /E /COPYALL /XJ /XD “C:\Users\Administrator” 注销Administrator,重新用你的用户名登录Windows7,而后到“计算机管理器”里禁用Administrator; 以管理员身份打开一个DOS窗口,输入以下命令: rmdir “C:\Users” /S /Q mklink /J “C:\Users” “D:\Users” 搞定。