为 C# Web 应用程序和库设置持续集成服务器

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

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

我的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 会将文件复制到目标服务器，该服务器在组策略启动脚本期间映射为网络驱动器（Windows 服务器与网络使用映射，LAMP 服务器与 Webdrive 映射）。

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

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

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

我们的大多数应用程序都是ASP，ASP.NET 或MVC Web应用程序。 TeamCity自动从Subversion中签出代码（由签入触发），编译任何需要编译的内容，将最新的页面和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 请求，并确保一切正常、运行和响应。

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

TeamCity 非常棒 - 我们现在已经获得了许可，因为我们需要 20 个项目（和 LDAP 身份验证>但免费版本多年来一直为我们服务，它是一款绝对很棒的软件。FinalBuilder 价格昂贵，但非常非常易于使用 - 如果您现金充裕且时间不足，那就去吧;如果你有更多的时间而不是金钱，坚持使用Nant或msBuild，并编写自己的步骤来编辑web.config文件等。

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

我认为最佳实践是：

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

我希望这有所帮助。

我目前的设置和最佳实践：

开发项目和环境：

• C++和 C# 应用程序，包括一些基于 Web 的 C# 应用程序。
• 视窗应用程序。
• 颠覆。
• ~30 全球开发人员访问集中式构建服务器。
• 开发人员提交到存储库的主干。

构建脚本：

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

构建脚本设计：

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

每日构建：

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

持续集成 （ci） 构建：

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

基本构建环境：（我们更复杂的项目都是基于这些原则构建的）

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

构建行为：

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

开发环境：

1. 开发人员执行批处理文件，将最新的 ci 生成输出获取到其开发计算机。
2. 开发人员和项目经理依靠 ci 构建状态，安装了 CCNet 托盘以获得构建的即时结果。
3. 开发人员有时会举行抽奖，看看谁破坏了构建，并通过在周五让他/她自下而上来惩罚啤酒。 :D

希望这有帮助。

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

一旦他们真正不得不掏钱，他们就会对持续集成的进展更感兴趣。