为C＃Web应用程序和库设置Continuous-Integration服务器

Question

我一直在测试Jenkins CI，现在是时候构建服务器了。什么是最好的方式？有很多选择，我不知道选择什么。

• 共享计算机，其他服务器随之运行，
• 虚拟机，位于用于其他服务器的计算机内
• 独立机器
• 使用具有不同操作系统的多台机器来测试每个平台？ （我有一些基于selenium的web UI测试）

而且，我想要使用操作系统的建议。我使用msbuild，可能只在Windows上可用...但是也许是Linux服务器，使用单声道的某种构建器可能是最好的方法。

我与詹金斯没有关系，但似乎是最好的。如果你知道更好的选择，请告诉我。

我需要意见，我需要知道存在哪些可能性，如果可能的话，要知道其他人在做什么，以及你对各种设置有什么经验，这样我才能做出可靠的决定。

谢谢！

Answer 1

首先要做的事情。我的CI服务器是运行CruiseControl.NET的VM。我不使用詹金斯，所以我不能真的评论它。从外观上看，Jenkins比CC.NET更发达。

根据虚拟与物理问题：最终，就CI而言，它并不重要。只要它在网络上可见并且有足够的资源来执行它的功能，其余的只是管理。就个人而言，我发现虚拟化的好处值得付出额外的努力。您可以轻松添加资源，移动其物理位置，支持其他VM来运行群集。 benefits of virtualization是众所周知的，现在每个人都在这样做。

我的CI服务器位于VMWare ESX服务器上，该服务器具有大量的CPU和RAM。它在其上运行许多其他VM。我有大约35个站点在CI中运行，可能有20个站点在计算机本身上，另外70个站点通过CI仪表板手动触发它们来构建。我从来没有遇到任何相关的性能问题。

理想情况下，您的构建服务器应具有与您计划部署代码的任何计算机相同的设置。对于网站，这将与您的生产服务器（可能是Windows 2003或2008）相同。对于桌面应用程序，我可能只会选择您目标支持并且可以负担得起的最新且最好的操作系统。

只有在构建要在多个操作系统上支持的桌面应用程序时，才能使用具有多个操作系统的多台计算机。在这种情况下，拥有多台服务器将是理想的，但我认为这需要很多工作才能完成。就我个人而言，我会从简单开始，让一切运行起来，并在真正有必要时开始添加碎片。

正如我所提到的，我使用的是CruiseControl.NET。到目前为止一直都很棒，我很高兴。由于它是用.NET编写的，并且您使用的是.NET，因此您的服务器需要运行的移动部件较少（我看到Jenkins是基于Java构建的）。编写插件/扩展在理论上会更容易，因为你已经有了内部的.NET人员。我从来没有写过CC.NET的扩展，所以我不能肯定地说，虽然我知道它是可能的。缺点是社区规模小，积极发展缓慢。

最后，我要补充一点，这将是很多工作要开始。我花了6个多月的时间让我的CI服务器准备好进行生产，还有一些用于迁移我们所有项目以进行生产，还有更多项目用于培训其他开发人员如何使用它或使用它。

所以，总结一下，

• 虚拟化很好！ （但这并不重要）。
• 如果可能，您应该将CI环境与您正在部署的任何环境相匹配。
• 你最好准备好长期承诺。
• 持续集成非常棒，您不会后悔设置CI服务器。无论你选择什么，它都会比以前的“牛仔编码”更好:)

编辑其他答案正在发布他们的流程，所以我想我也应该这样做！ ：）

我的商店建立了LAMP和.NET网站，所以我们需要一些可以有效工作的东西。我们将CC.NET作为核心框架运行，但几乎所有功能都由自定义Nant脚本执行。我们使用Nant，因为它是1）基于.NET并且内置了.NET命令，2）易于执行命令行操作，这些操作构成了我们所有构建步骤的核心。

CC.NET侦听SVN服务器并在进行更新时获取更新。 CC.NET将它们检出并触发执行所有实际工作的NANT任务。对于.NET，这意味着mstest进行单元测试，msbuild进行构建和发布。 PHP通常只是将文件直接移动到目标环境。然后，如果所有步骤都成功，Robocopy会将文件复制到目标服务器，目标服务器在Group Policy startup script期间映射为网络驱动器（Windows服务器映射为net use和LAMP服务器用Webdrive）映射。

我们有开发服务器，登台/ QA服务器和生产服务器。由于我们在.NET和LAMP中工作，因此每个阶段的每个环境都有一个服务器 - 总共6个，都是虚拟的。我们的开发服务器是唯一设置为持续集成构建的服务器。分段和生产仅与其他一些SVN魔法一起强制构建，以防止意外部署。我们还使用MXMLC构建和单元测试AcrionScript，但这对我们来说很少见。

Answer 2

这是我们的设置。我们有两个虚拟服务器（一个构建服务器和一个测试服务器），然后是两个生产服务器。

构建服务器正在运行TeamCity（用于CI）和FinalBuilder（用于一些更复杂的构建作业，涉及编辑XML文件，更改配置设置，安装和注册Windows服务）。

我们的大多数应用程序都是ASP，ASP.NET或MVC Web应用程序。 TeamCity自动检查subversion中的代码（由checkin触发），编译需要编译的任何内容，将最新的页面和DLL部署到构建盒上运行的IIS Web服务器。

我们所有的网站都在IIS中设置了多个主机标头，因此同一网站正在收听www.mysite.com.build，www.mysite.com.test，www.mysite.com。我们在域控制器上设置了DNS通配符别名，以便* .build指向构建服务器，* .test指向测试服务器，依此类推。

这意味着只要代码已经由TeamCity提交并构建，公司中的每个人都可以在www.whatever.com.build上看到它。

然后又有一个TeamCity作业使用msdeploy.exe将各个网站（包括他们的虚拟应用程序和子文件夹）从构建服务器推送到测试服务器。

在每个阶段，TeamCity都会运行作为项目一部分的任何单元测试，并运行一个单独的项目，对我们网站上的各种关键URL执行HTTP请求，并确保一切正常，运行和响应。

最后，还有一个“上线”任务，可以将ENTIRE服务器从测试到实时部署。这意味着完整的服务器配置完全由TeamCity控制，它不鼓励在实时服务器上进行配置更改，因为在下次部署期间您的更改将被覆盖。

TeamCity非常棒 - 我们现在已获得许可，因为我们需要＆gt; 20个项目（和LDAP身份验证），但免费版本为我们提供了很多年，它是一个绝对令人敬畏的软件。 FinalBuilder价格昂贵但非常非常容易使用 - 如果你现金充裕且时间不长，那么就去购买它;如果你有更多的时间而不是钱，坚持Nant或msbuild并编写自己的步骤来编辑web.config文件等。

编辑：我错过的另一个细节 - 我们有一个测试和一个实时数据库服务器。编码器的工作站和.build服务器都设置为使用测试数据库; * .test和实时服务器与实时数据通信。我们使用SQL Compare（手动）将模式更改从测试SQL服务器推送到实时SQL服务器，但通常TeamCity只是在构建和测试之间调整配置文件以切换数据库连接字符串。

Answer 3

我认为最佳做法是：

1. 单独的构建服务器（如果它是否是垂直的，则无关紧要）
2. 构建服务器在签入时构建代码
3. 有一个单独的部署服务器进行测试（再次虚拟无关紧要）
4. 让您的构建部署到测试服务器（您可以为此构建单独的构建，即CI构建和构建和部署构建以进行测试）
5. 我将在构建服务器上运行的任何单元或集成测试，手动测试在测试服务器上完成

我希望这会有所帮助。

Answer 4

我目前的设置和最佳做法：

开发项目和环境：

• C ++和C＃应用程序，包括一些基于Web的C＃应用​​程序。
• Windows应用程序。
• 颠覆。
• 〜全球30位开发人员访问集中构建服务器。
• 开发人员承诺存储库的主干。

构建脚本：

1. 我们使用Visual Build Professional，VBP，www.kinook.com作为企业构建工具。
2. 构建脚本按层次结构设计为构建脚本层，这些脚本执行不同的功能并可以重复使用。

构建脚本设计：

1. 构建机器层 - 检查所需构建工具的列表，从SVN中继检出源代码。
2. SVN层 - 执行分支，版本控制，提交和切换回主干。
3. 构建产品层 - 构建N个子构建脚本的构建脚本，其中1个子构建脚本= 1个项目（不是VS项目）。 （开发人员友好）
4. 子构建脚本层 - 定义要构建的C＃/ C ++解决方案的集合。还定义构建顺序依赖项。使用MSBuild / t：重建来构建解决方案。使用devenv建立特殊项目。 （开发人员友好）

每日构建：

• 在构建脚本设计中构建1.到4.

持续集成（ci）构建：

• 构建脚本设计中的构建3.和4.

基本构建环境:(我们更复杂的项目建立在这些原则的基础上）

1. 将每日构建服务器与持续集成构建服务器分开，在每次成功的持续集成构建之后，还将测试服务器分开以进行测试。 （1 x每日构建服务器，1 x ci构建服务器，N x测试服务器）
2. 具有多个CPU的Windows服务器的VM作为构建计算机。 （对于MSBuild / m）
3. 其他Windows操作系统作为测试机器。
4. Cruise Control.NET，CCNet，安装在所有构建/测试机器上。
5. 由CCNet控制的每日构建，每天在预定时间运行。
6. CCNet在提交时触发的持续集成构建。

构建行为：

1. 每日构建从午夜开始，将构建输出发布到网络共享驱动器，例如：\ share \ daily_build。 （是的，我们仍然使用共享驱动器。）：）
2. 每日成功构建后，将自动触发ci build以清理工作副本，检查源代码并从头开始构建。 （MSBuild / t：Build）
3. CI build然后将构建的二进制输出复制到网络共享驱动器，例如：\ share \ ci_build。 （注意，2个不同的文件夹，1个用于每日构建，1个用于ci构建）

开发环境：

1. 开发人员执行批处理文件，获取最新的ci构建输出到他们的开发机器。
2. 开发人员和项目经理依赖于ci构建状态，安装了CCNet Tray以立即获得构建结果。
3. 开发商有时会举行彩票活动，看看谁打破了这个版本，并在星期五让他/她的底部装满了啤酒。 ：d

希望这有帮助。

Answer 5

我建议使用一个单独的物理构建服务器，原因很简单......它得到了管理层的支持。

一旦他们真的不得不掏钱，他们就会对持续整合的方式产生更多的兴趣。