用MSBuild和Jenkins搭建持续集成环境

你或其他人刚刚写完了一段代码，提交到项目的版本仓库里面。但等一下，如果新提交的代码把构建搞坏了怎么办？万一出现编译错误，或者有的测试失败了，或者代码不符合质量标准所要求的底限，你该怎么办？

最不靠谱的解决方案就是寄希望于所有人都是精英，他们根本不会犯这些错误。但如果真的出现了这些问题，我们就希望发现的越早越好。最好的方式就是只要有代码提交，我们就有某种方式对它进行验证。这就是持续集成的作用。

持续集成相关的工具有很多。最流行的要数一款基于Java的名叫Jenkins的工具。它提供了Web界面，用户可以在界面上配置Job，每个Job都包含一系列的构建步骤。Jenkins可以完成开头那个场景中所提到的所有验证工作，它还能更进一步做自动化部署或者一键式部署。

Jenkins是由Sun的前员工开发的，它的根基是Java，但也可以用在非Java的项目里，比如PHP、Ruby on Rails、.NET。在.NET项目里，你除了Jenkins之外还要熟悉另一样工具：MSBuild。

Visual Studio用MSBuild构建.NET项目。MSBuild所需的仅仅是一个脚本，在脚本中指定要执行的target。项目中的.csproj和.vbproj 文件都是MSBuild脚本。

在这篇文章中，我们会从头开始，一步步完成一个属于我们自己的MSBuild脚本。在它完成以后，我们只需要一个命令就可以删除之前的构建产物，构建.NET应用，运行单元测试。后面我们还会配一个Jenkins Job，让它从代码库中更新代码，执行MSBuild脚本。最后还会配另一个Jenkins Job，让它监听第一个Job的结果，当第一步成功以后，它会把相关的构建产物复制出来，放到web服务器里启动运行。

我们用一个ASP.NET MVC 3应用做例子，在VS里面创建ASP.NET MVC 3应用并选择“application”模版就行。我们还要用一个单元测试项目来跑测试。代码可以在这里下载。

你好，MSBuild

MSBuild是在.NET 2.0中引入的针对Visual Studio的构建系统。它可以执行构建脚本，完成各种Task──最主要的是把.NET项目编译成可执行文件或者DLL。从技术角度来说，制作EXE或者DLL的重要工作是由编译器（csc，vbc等等）完成的。MSBuild会从内部调用编译器，并完成其他必要的工作（例如拷贝引用──CopyLocal，执行构建前后的准备及清理工作等）

这些工作都是MSBuild执行脚本中的Task完成的。MSBuild脚本就是XML文件，根元素是Project，使用MSBuild自己的命名空间。MSBuild文件都要有Target。Target由Task组成，MSBuild运行这些Task，完成一个完整的目标。Target中可以不包含Task，但是所有的Target都要有名字。

下面来一起创建一个“Hello World”的MSBuild脚本，先保证配置正确。我建议用VS来写，因为它可以提供IntelliSense支持，不过用文本编辑器也无所谓，因为只是写个XML文件，IntelliSense的用处也不是很大。先创建一个XML文件，命名为“basics.msbuild”，这个扩展名只是个约定而已，好让我们容易认出这是个MSBuild脚本，你倒不用非写这样的扩展名。给文件添加一个Project元素作为根元素，把 http://schemas.microsoft.com/developer/msbuild/2003设置成命名空间，如下所示

下一步，给Project元素添加一个Target元素，起名叫“EchoGreeting”

这就行了。我们已经有了一个可以运行的MSBuild脚本。它虽然还啥事都没干，但我们可以用它来验证当前环境是不是可以运行MSBuild脚本。在运行脚本的时候，我们要用到.NET框架安装路径下的MSBuild可执行文件。打开命令行，执行“MSBuild /nologo /version”命令，看看.NET框架安装路径是不是放到了PATH环境变量里面。如果一切正确，你应该能看到屏幕上打印出MSBuild的当前版本。倘若没有的话，或者把.NET框架安装路径放到PATH里面去，或者直接用Visual Studio Command Prompt，它已经把该配的都配好了。

进入存放刚才那个脚本的目录后，以文件名当作参数调用MSBuild，就可以执行脚本了。在我的机器上可以看到下面的执行结果：

C:\>msbuild basics.msbuild
Microsoft (R) Build Engine Version 4.0.30319.1
[Microsoft .NET Framework, Version 4.0.30319.269]
Copyright (C) Microsoft Corporation 2007. All rights reserved.

Build started 8/2/2012 5:59:45 AM.

Build succeeded.
 0 Warning(s)
 0 Error(s)
Time Elapsed 00:00:00.03

执行完脚本以后，MSBuild会首先显示一个启动界面和版权信息（用 /nologo 开关可以隐藏掉它们）。接下来会显示一个启动时间，然后便是真正的构建过程。因为咱们的脚本啥都没干，所以构建就直接成功了。总计用时也会显示在界面上。下面咱们来给EchoGreeting Target添加一个Task，让脚本真的干点事。

    lt;Exec Command="echo Hello from MSBuild" />

现在EchoGreeting Target有了一个Exec Task，它会执行Command属性中定义的任何命令。再运行一次脚本，你应该能看到更多信息了。在大多数时候，MSBuild的输出信息都很长，你可以用 /verbosity 开关来只显示必要信息。不过无论怎样，MSBuild都会把我们的文字显示到屏幕上。下面再添加一个Target。

这个Target会输出当前日期。它的命令要做的事情就是“echo %25date%25”，但是“%”字符在MSBuild中有特殊含义，所以这个命令需要被转义。当遇到转义字符的时候，“%”后面的十进制字符会被转成对应的ASCII码。MSBuild只会执行Project元素中的第一个Target。要执行其他Target的时候，需要把/target开关（可简写为 /t）加上Target名称传给MSBuild。你也可以指定MSBuild执行多个Target，只要用分号分割Target名字就可以。

C:\>msbuild basics.msbuild /nologo /verbosity:minimal /t:EchoGreeting;EchoDate
 Hello from MSBuild
 Thu 08/02/2012

更实用的构建脚本

演示就先到这里。下面来用MSBuild来构建一个真实项目。首先把示例代码下载下来，或是自己创建一个ASP.NET应用。给它添加一个MSBuild脚本，以solution或project名字给脚本命名，扩展名用“.msbuild”。照先前一样指定MSBuild命名空间。

开始写脚本之前，先把脚本要干的事情列出来：

1. 创建BuildArtifacts目录
2. 构建solution，把构建产物（DLL，EXE，静态内容等等）放到BuildArtifacts目录下。
3. 运行单元测试。

因为示例应用叫做HelloCI，于是这个脚本也就命名为HelloCI.msbuild。先添加命名空间，然后就可以添加第一个Target了，我管它叫做Init。

这个Target会调用MakeDir Task创建一个新的目录，名叫BuildArtifacts，跟脚本在同一目录下。运行脚本，你会发现该目录被成功创建。如果再次运行，MSBuild就会跳过这个Task，因为同名目录已经存在了。

接下来写一个Clean Target，它负责删除BuildArtifacts目录和里面的文件。

理解了Init之后，这段脚本就应该很好懂了。试着执行一下，BuildArtifacts目录应该就被删掉了。下面再来把代码中的重复干掉。在Init和Clean两个Target里面，我们都把BuildArtifacts的目录名硬编码到代码里面了，如果未来要修改这个名字的话，就得同时改两个地方。这里可以利用Item或Property避免这种问题。

Item和Property只有些许差别。Property由简单的键值对构成，在脚本执行的时候还可以用 /property 赋值。Item更强大一些，它可以用来存储更复杂的数据。我们这里不用任何复杂数据，但需要用Items获取额外的元信息，例如文件全路径。

接下来修改一下脚本，用一个Item存放路径名，然后修改Init和Clean，让它们引用这个Item。

Item是在ItemGroup里面定义的。在一个Project中可以有多个ItemGroup元素，用来把有关系的Item分组。这个功能在Item较多的时候特别有用。我们在ItemGroup里定义了BuildArtifactsDir元素，并用Include属性指定BuildArtifacts目录。记得BuildArtifacts目录后面要有个斜杠。最后，我们用了@(ItemName)语法在Target里面引用这个目录。现在如果要修改目录名的话，只需要改BuildArtifactsDir的Include属性就好了。

接下来还有个问题要处理。在BuildArtifacts目录已经存在的情况下，Init是什么事都不干的。也是就说，在调用Init的时候磁盘上的已有文件还会被保留下来。这一点着实不妥，如果能每次调用Init的时候，都把目录和目录里面的所有文件都一起删掉再重新创建，就能保证后续环节都在干净的环境下执行了。我们固然可以在每次调用Init的时候先手工调一下Clean，但给Init Target加一个DependsOnTargets属性会更简单，这个属性会告诉MSBuild，每次执行Init的时候都先执行Clean。

现在MSBuild会帮我们在调Init之前先调Clean了。跟DependsOnTargets这个属性所暗示的一样，一个Target可以依赖于多个Target，之间用分号分割就行。

接下来我们要编译应用程序，把编译后的结果放到BuildArtifacts目录下。先写一个Compile Target，让它依赖于Init。这个Target会调用另一个MSBuild实例来编译应用。我们把BuildArtifacts目录传进去，作为编译结果的输出目录。

 
 



 Release
 Any CPU



 

上面的脚本做了几件事情。首先，ItemGroup添加了另一个Item，叫做SolutionFile，它指向solution文件。在构建脚本中用Item或Property代替硬编码，这算的是一个优秀实践吧。

其次，我们创建了一个PropertyGroup，里面包含两个Property：Configuration和BuildPlatform。它们的值分别是“Release”和“Any CPU”。当然，Property也可以在运行时通过/property（简写为/p）赋值。我们还用了Condition属性，它在这里的含义是，只有当这两个属性没有值的情况下，才用我们定义的数据给它们赋值。这段代码实际上就是给它们一个默认值。

接下来就是Compile Target了，它依赖于Init，里面内嵌了一个MSBuild Task。它在运行的时候会调用另外一个MSBuild实例。在脚本中定义了这个被内嵌的MSBuild Task要操作的项目。在这里，我们既可以传入另外一个MSBuild脚本，也可以传入.csproj文件（它本身也是个MSBuild脚本）。但我们选择了传入HelloCI应用的solution文件。Solution文件不是MSBuild脚本，但是MSBuild可以解析它。脚本中还指定了内嵌的MSBuild Task要执行的Target名称：“Rebuild”，这个Target已经被导入到solution的.csproj文件中了。最后，我们给内嵌的Task传入了三个Property。

OutDir

          编译结果的输出目录

Configuration

          构建（调试、发布等）时要使用的配置

Platform

          编译所用的平台（x86、x64等）

给上面这三个Property赋值用的就是先前定义的Item和Property。OutDir Property用的是BuildArtifacts目录的全路径。这里用了%(Item.MetaData) 语法。这个语法应该看起来很眼熟吧？就跟访问C#对象属性的语法一样。MSBuild创建出来的任何Item，都提供了某些元数据以供访问，例如FullPath和ModifiedTime。但这些元数据有时候也没啥大用，因为Item不一定是文件。

Configuration和Platform用到了先前定义好的Property，语法格式是$(PropertyName)。在这里可以看到系统保留的一些属性名，用户不能更改。定义Property的时候请不要用它们。

这里还有些东西值得提一下。用了Property以后，我们可以在不更改构建脚本的情况下使用不同的Configuration或者BuildPlatform，只要在运行的时候用 /property 传值进去就行。所以“msbuild HelloCI.msbuild /t:Compile /p:Configuration:Debug”这个命令会用Debug配置构建项目，而“msbuild HelloCI.msbuild /t:Compile /p:Configuration:Test;BuildPlatform:x86”会在x86平台下使用Test配置。

现在运行Compile，就可以编译solution下的两个项目，把编译结果放到BuildArtifacts目录下。在完成构建脚本之前，只剩下最后一个Target了：

ItemGroup里现在又多了三个Item：NUnitConsole指向NUnit控制台运行器（console runner）；UnitTestDLL指向单元测试项目生成的DLL文件；TestResultsPath是要传给NUnit的，这样测试结果就会放到BuildArtifacts目录下。

RunUnitTests Target用到了Exec Task。如果有一个测试运行失败，NUnit控制台运行器会返回一个非0的结果。这个返回值会告诉MSBuild有个地方出错了，于是整个构建的状态就是失败。

现在这个脚本比较完善了，用一个命令就可以删除旧的构建产物、编译、运行单元测试：

C:\HelloCI\> msbuild HelloCI.msbuild /t:RunUnitTests

我们还可以给脚本设一个默认Target，就省得某次都要指定了。在Project元素上加一个DefaultTargets属性，让RunUnitTests成为默认Target。

你还可以创建自己的Task。这里有个例子，AsyncExec，它允许人们以异步的方式执行命令。比如有个Target用来启动Web服务器，要是用Exec命令的话，整个构建都会停住，直到服务器关闭。用AsyncExec这个命令可以让构建继续执行，不用等待命令执行结束。

本文的完整脚本可以在这里下载。

在接下来的文章中，我会讲述如何配置Jenkins。我们不再需要手动运行命令来构建整个项目，Jenkins会检测代码库，一旦有更新就会自动触发构建。

作者简介

Mustafa Saeed Haji Ali居住在Somaliland的Hargeisa。他是个程序员，最常用的是ASP.NET MVC。Mustafa喜欢测试，喜欢用Javascript框架，如KnockoutJS、AngularJS、SignalR。他热衷于传播最佳实践。

 

 

查看英文原文：Continuous Integration with MSBuild and Jenkins – Part 1

与Jenkins相会

Jenkins在2004年由Kohsuke Kawaguchi创建，最开始的名字叫Hudson。Kawaguchi当时在Sun工作，Sun直到2008年一直为Hudson提供支持，但是当它被Oracle收购以后，Oracle和Hudson的开发者社区出现了分歧。2011年，Oracle宣称了对Hudson商标的所有权，Hudson开发社区于是将Hudson改名叫Jenkins，摆脱了Oracle的干扰，继续开发工作。

第一眼看上去，Jenkins像是一个专为Java项目准备的持续集成工具：有为Maven项目设计的job，有诸多为Java项目提供的默认插件，更不要说那些用Java写的插件了。

但Jenkins其实是一个非常灵活的工具，它可以结合各种版本管理系统和构建工具，用来构建任何类型的项目。在这篇文章中，我们会利用它的灵活性，从Mercurial中pull代码，用MSbuild构建项目。首先，我们需要下载并安装Jenkins，然后安装Mercurial和MSBuild插件。

配置Jenkins

从官方网站下载安装程序。它的Windows安装包很简单，会把Jenkins安装成Windows服务。Jenkins的默认的访问路径是http://localhost:8080，请确保8080端口不要被其他应用占用。

安装完毕以后就是装插件。请点击“Manage Jenkins”链接，然后再点击“Manage Plugins”。在“Available”标签页可以查看当前可安装的插件──你需要有一个能上网的环境，才能看到这一页的内容。用filter找到Mercurial和 MSBuild插件，点击插件名称前面的单选框，进行安装。你可以点击“Installed”标签页，来确保这两个插件已经被安装成功了。在安装过程中，你可能会看到提示信息说Jenkins需要重启才能完成安装，请让它重启，等重启完成后再访问“Installed”标签页，看看是不是安装成功。

Mercurial插件还需要做一些配置，才能让Jenkins找到Mercurial的安装路径。回到“Manage Jenkins”这一页上来，点击“Configure System”，找到“Mercurial”这一部分──如果你找不到“Mercurial”的话，就说明Mercurial插件没有装好──点击“Add Mercurial”按钮之后，你需要给这个Mercurial实例起个名字（自己用着越方便越好）；还需要输入Mercurial可执行文件的安装路径，这里用的是hg.exe文件的所在目录；最后是可执行文件的名字，就用“INSTALLATION/hg.exe”就好，INSTALLATION这个单词会被前面输入的安装路径替换掉。

创建一个Jenkins Job

点击“Back to Dashboard”，回到Dashboard上来，然后点击“New Job”链接。你会看到一组job类型，选择“Build a free-style software project”，给它命名为“HelloCI-RunUnitTests”，点击OK。

下一步是job配置页面。这一页有很多配置项，而且大多数都带有详细的描述信息，点击右侧的帮助图标就可以看到。我们现在只配置两部分，一是代码库所在位置，二是如何用MSBuild构建项目。

找到“Source Code Management”，选择Mercurial。在“Mercurial Version”输入框中输入先前在“Configure System”中配置的Mercurial名称。然后在Repository URL中输入Mercurial版本库的URL（也可以是一个文件系统的路径）。最后在Branch中输入你想跟踪的分支名。

接下来到“Build”这部分。点击“Add build step”按钮后，下拉框中就会出现一系列的step类型以供选择，其中便包括“Build a Visual Studio project or solution using MSBuild”，如果你没看到这个选项，就说明MSBuild插件没有正确安装。

点击“Build a Visual Studio project or solution using MSBuild”之后，在“MSBuild Build File”输入框中输入构建脚本的名字：HelloCI.msbuild。我们想让Jenkins执行“RunUnitTests”这个Target ，如果你没有把DefaultTargets属性设成RunUnitTests的话，可以在“Command Line Arguments”中输入“/t:RunUnitTests”，其中/t是/target的简写。

点击“Save”或“Apply”保存之后，这个job一旦被触发，就可以pull代码下来，编译项目，执行单元测试。我们先来手工触发一次，看看配置是否正确。先回到Dashboard，这时可以在屏幕中央看到我们的job。点击job名字，然后在左侧的链接中找到“Build Now”链接，点击它，Jenkins就会开始执行。在这组链接的下方有一个“Build History”列表，它显示的是这个job的所有构建历史，当第一次构建开始运行的时候，你会在列表中看到一个进度条，同时还有一个小圆球显示构建状态。圆球闪烁表示构建正在进行中，它停止闪烁的时候一般会是红色或蓝色，红色表示构建失败，蓝色表示成功。

如果这个job能够访问Mercurial版本库，找到了HelloCI.msbuild脚本，“RunUnitTest”执行成功，这个圆球应该会变蓝。这时候你也就顺利完成了第一个Jenkins构建。如果构建失败，请点击“Build History”对应的编号查看详细信息，然后点击“Console Output”，就可以看到Jenkins所执行的每一个命令和对应结果，从中可以分析出构建失败的原因。

触发构建

构建成功以后，下一步要做的就是让Jenkins检测版本库的变化，一旦有代码提交，Jenkins就要pull代码并执行构建。有好几种方法可以做到这一点。最简单的就是让Jenkins定时构建，但是如果在这一段时间内没有代码提交，这次构建反而是浪费。另一种方式是让Jenkins定时轮询，看看版本库中是否有代码提交。这种方法的缺点是当有了代码提交以后，Jenkins要等到下一个轮询周期才能执行构建。当然，你也可以让Jenkins每分钟都轮询一次，尽可能缩短等待时间，但我们还有另一种更优雅的方案──给Mercurial版本库中放一个post-commit的钩子，这样一旦版本库接受了新代码，它都会通知Jenkins，让它立刻开始构建。

这个方法需要在.hg目录下的配置文件中（.hgrc）添加一个钩子。在这个钩子里面，你需要让Mercurial访问下面这个网址：http://localhost:8080/job/JOBNAME/build?delay=0sec（JOBNAME需要替换成真实的job名称），让Jenkins启动构建。但不幸的是，Windows下没有类似Linux wget这样可以进行HTTP请求的工具。我自己写了行Ruby代码来做这项工作。你也可以用Powershell来创建一个System.Net.WebClient的实例，然后调用DownloadString方法。读者朋友可以自己完成这项工作，权当练习吧。

如果你不愿意用这个方法，就还用轮询吧。回到job配置页面，在“Build Trigger”区域选择“Poll SCM”，在“Schedule”输入框中输入轮询周期。它采用的语法格式是cron的风格。如果要每分钟轮询一次，就输入“1 * * * *”。你可以点击输入框右侧的帮助按钮，查看轮询周期的语法介绍。

构建流水线

Jenkins可以在某个构建成功结束之后启动其他job。于是就有了构建流水线，它的概念就是一个job成功之后触发其他job。触发者叫做上游job，被触发者被称作下游job。

构建流水线的应用场景有很多：让耗时较长的测试在单元测试结束之后执行；运行静态代码检查；把构建结果部署到试机环境（staging）或者产品环境中。我们下面来演示一下这个功能，让Jenkins在构建结束后启动web服务器，运行HelloCI这款应用。

我们只需要做三件事情：HelloCI-RunUnitTests job成功之后触发一个新job；把HelloCI-RunUnitTests的构建结果拷贝出来；启动web服务器。在开始之前，你还需要安装Copy Artifacts插件。回到Manage Plugins页面，参考之前安装Mercurial插件的方法安装Copy Artifacts。在看到重启的提示信息时重启Jenkins。

创建新job之前，我们需要告诉HelloCI-RunUnitTests job，让它把构建产物保存下来，以供新job使用。回到HelloCI-RunUnitTests job的配置界面，找到“Post-build Action”，选中“Archive the artifacts”，页面上就会出现一个文本框：“Files to archive”。我们要存档的目录有两份，一份是BuildArtifacts目录，一份是packages目录，后者是为了让我们能够访问NuGet package。如果要指定某个目录以及目录下所有内容，就需要在目录后面跟一个斜杠和两个星号。不同的目录或文件之间用逗号分割。在这里我们输入的是“BuildArtifacts/**，packages/**”。

现在创建一个新job，起名叫“HelloCI-StartWebServer”。在配置页面上“Build Triggers”那一节里选中“Build after other projects are built”，把之前那个job配置成要触发当前job的项目。

接下来给job添加一个build step，让这个job所做的第一件事情就是拷贝之前job所保存的构建产物。这里要用到“Copy artifacts from another project”这个step（它是由Copy Artifacts插件提供的）。我们只需要填入HelloCI-RunUnitTests job的名字就可以。

最后还要添加一个build step，让它启动web server。这里用的是“Execute Windows batch command”，我们用Visual Studio提供的Cassini来运行应用。Cassini可以在“C:\Program Files (x86)\Common Files\microsoft shared\DevServer\10.0\WebDev.WebServer40.EXE”找到。运行Cassini很简单，把web应用存放的路径作为参数传给它就行，如果没有指定端口号的话，它就会使用默认的端口号80。

“Execute Windows batch command”step需要一个可以在BuildArtifacts和packages拷贝后的目录下执行的命令。我们把下面这个命令复制到“Command”输入框中：

"C:\Program Files (x86)\Common Files\microsoft shared\DevServer\10.0\WebDev.WebServer40.
EXE" /port:9876 /path BuildArtifacts/_PublishedWebsites/HelloCI.Web/.

这个命令可以启动Cassini，把它指向拷贝过来的应用，然后在9876端口启动服务器。

所有的配置都已就绪。试着修改一下代码然后提交。Jenkins应该能够监听到变化，运行HelloCI-RunUnitTests。如果代码编译成功，所有测试均以通过，Jenkins应该开始运行HelloCI-StartWebServer job，把HelloCI-RunUnitTests的构建产物拷贝过来，在9876端口启动Cassini。如果这一切都运行无误，我们的持续集成系统就搭好了。

结尾

MSBuild和Jenkins可讲的地方还很多。比如说可以从持续集成走向持续部署。你所需要的只是一个job，让它把构建产物部署到生产环境（译者注：持续部署殊非易事，作者有些夸大其词，读者请勿轻信）。ASP.NET的应用就更简单了，用一个job把构建产物复制到某个目录下就行。这样一来，只要所有的测试全都通过，这个Jenkins job就可以把最新特性发布到生产环境上去。

如果你还没做好准备走那么远，也可以用一下Promoted Build plugin，它可以在某个构建达到了一个特定的标准之后，把它标记为“推荐使用”。一个人或几个人手工审核过一个构建，也算得是达到了推荐标准。有了Promoted Build plugin，人们做出的修改就可以自动发布到开发服务器上，所有的新功能都集中呈现。开发经理而后可以把某个特定的构建推荐到试机环境中。QA团队或其他干系人可以进行验收（其方式就是推荐试机环境上的构建），然后这个构建就可以由Jenkins部署到产品环境上。

John Ferguson Smart曾写过一本很出色的书，叫做“Jenkins: The Definitive Guide”。这本书除了讲述Jenkins的功能之外，还描述了怎么保证Jenkins的安全，怎样检测资源使用（如磁盘占用），怎样进行分布式构建，直到设置通知系统，让用户在构建开始、成功、失败的时候得到通知。这本书由O'Reilly出版，购买地址在此。如果你对Jenkins还不太了解的话，本书就属于必看的一本。

拥有一个自动化的构建部署系统，就跟要看重测试，要使用版本控制系统一样重要。我希望你已经熟练掌握了如何设置持续集成系统，可以开始着手集成自己的系统。

一开始不要太激进，一心想着把所有事情都做好。你可以一点一点来。你终会享受到胜利果实的。当Jenkins通知你某个构建失败的时候，你发现bug的时机就提前了；当你再也不用记忆每一步部署的操作时，你就有了一整套系统化的部署流程。而更重要的是，你有了更多时间去做更重要的事情，比如开发有价值的特性，或是为新项目做准备，也可以提前下班回家，再也不用为即将到来的上线担忧。

关于作者

Mustafa Saeed Haji Ali居住在Somaliland的Hargeisa。他是个程序员，最常用的是ASP.NET MVC。Mustafa喜欢测试，喜欢用Javascript框架，如KnockoutJS、AngularJS、SignalR。他热衷于传播最佳实践。

查看英文原文：Continuous Integration with MSBuild and Jenkins – Part 2