我如何以及为啥要设置 C# 构建机器？ [关闭]

Posted 2023-02-19

【中文标题】我如何以及为啥要设置 C# 构建机器？ [关闭]

【英文标题】：How and why do I set up a C# build machine? [closed]我如何以及为什么要设置 C# 构建机器？ [关闭]

【发布时间】：2010-10-11 14:19:28

【问题描述】：

我正在与一个小型（4 人）开发团队合作开发一个 C# 项目。我建议设置一台构建机器，它会在夜间对项目进行构建和测试，因为我知道这是一件好事。麻烦的是，我们这里没有很多预算，所以我必须向当权者证明费用是合理的。所以我想知道：

我需要什么样的工具/许可证？现在，我们使用 Visual Studio 和 Smart Assembly 进行构建，使用 Perforce 进行源代码控制。我是否需要其他东西，或者是否有相当于运行自动化脚本的 cron 作业？ 除了表明构建损坏之外，这究竟会给我带来什么？我是否应该在此解决方案（sln 文件）中设置将由这些脚本运行的测试项目，以便我可以测试特定的功能？目前，我们有两个这样的测试，因为我们没有时间（或者坦率地说，经验）来进行良好的单元测试。 我需要什么样的硬件？ 构建完成并经过测试后，将构建放在 ftp 站点上还是通过其他方式进行内部访问是一种常见的做法？我们的想法是，这台机器进行 构建，我们都去它，但如果需要，可以进行调试构建。 我们应该多久进行一次这种构建？ 如何管理空间？如果我们在夜间进行构建，我们应该保留所有旧构建，还是在大约一周左右后开始放弃它们？ 还有什么我没有在这里看到的吗？

我意识到这是一个非常大的话题，我才刚刚开始。我在这里找不到这个问题的副本，如果那里有我应该得到的书，请告诉我。

编辑：我终于让它工作了！ Hudson 非常棒，FxCop 表明我们认为实现的一些功能实际上是不完整的。我们还必须将安装程序类型从 Old-And-Busted vdproj 更改为 New Hotness WiX。

基本上，对于那些关注的人来说，如果您可以从命令行运行您的构建，那么您可以将其放入 hudson。通过 MSBuild 从命令行运行构建本身就是一个有用的练习，因为它强制您的工具是最新的。

【问题讨论】：

太棒了，很高兴听到你喜欢 Hudson :) 是不是很难想象现在没有 CI 平台的生活？

这很难。这种改变非常值得。

【参考方案1】：

更新：Jenkins 是 Hudson 的最新版本。现在每个人都应该使用 Jenkins。我会相应地更新链接。

Hudson 是免费的，并且非常易于配置，并且可以轻松地在 VM 上运行。

部分来自我的旧帖子：

我们用它来

部署 Windows 服务 部署网络服务 运行 MSTest 并显示与任何 junit 测试一样多的信息 跟踪低、中、高任务 趋势图警告和错误

以下是 Hudson 支持的一些内置 .net 内容

MSBuild NAnt MSTest Nunit Team Foundation Server fxcop stylecop compiler warnings code tasks

另外，上帝禁止你使用视觉源安全，it supports that as well。我建议你看看Redsolo's article on building .net projects using Hudson

您的问题

问：我需要什么样的工具/许可证？现在，我们使用 Visual Studio 和 Smart Assembly 进行构建，使用 Perforce 进行源代码控制。我是否需要其他东西，或者是否有一个相当于运行自动化脚本的 cron 作业？

答：我刚刚在一个新的 VM 副本上安装了 Visual Studio，该 VM 运行一个全新的、修补过的 Windows 服务器操作系统安装。所以你需要许可证来处理它。 Hudson 将自己安装为 Windows 服务并在端口 8080 上运行，您将配置您希望它扫描您的代码存储库以获取更新代码的频率，或者您可以告诉它在特定时间构建。都可以通过浏览器进行配置。

问：除了表明构建损坏之外，这究竟会给我带来什么？我是否应该在此解决方案（sln 文件）中设置将由这些脚本运行的测试项目，以便我可以测试特定的功能？目前，我们有两个这样的测试，因为我们没有时间（或者坦率地说，经验）来进行良好的单元测试。

答：首次构建失败或变得不稳定时，您会收到一封电子邮件。如果单元测试失败，或者可以通过您设置的任意数量的标准将其标记为不稳定，则构建是不稳定的。当单元测试或构建失败时，您将收到电子邮件，它会告诉您失败的位置、原因和方式。通过我的配置，我们得到：

自上次工作构建以来的所有提交列表 提交这些提交的注释 提交中更改的文件列表 构建本身的控制台输出，显示错误或测试失败

问：我需要什么样的硬件？

答：一个虚拟机就足够了

问：一旦构建完成并经过测试，将构建放在 ftp 站点上还是通过其他方式进行内部访问是一种常见的做法？这个想法是，这台机器进行构建，我们都去它，但如果我们必须进行调试构建。

答： Hudson 可以用它做任何你想做的事情，包括通过 md5 散列对其进行识别、上传、复制、存档等。它会自动执行此操作并为您提供具有悠久的构建工件历史。

问：我们应该多久进行一次这种构建？

答：我们每小时轮询一次 SVN，寻找代码更改，然后运行构建。每晚都可以，但在 IMO 中有点毫无价值，因为你昨天所做的工作在你早上进来时不会在你的脑海中记忆犹新。

问：空间如何管理？如果我们每晚构建，我们应该保留所有旧构建，还是在大约一周左右后开始放弃它们？

答：这取决于你，经过这么长时间我将我们的构建工件移动到长期存储或删除它们，但所有存储在我保留的文本文件/xml文件中的数据，这让我可以在服务器上存储更改日志、趋势图等，而消耗的空间很小。您还可以将 Hudson 设置为仅保留来自后续 # 次构建的工件

问：这里还有什么我没有看到的吗？

答：不，现在就去找哈德森，你不会失望的！

【讨论】：

很好的答案！我只用过 CruiseControl，但 Hudson 卖得不错。

感谢您的指点——Hudson 看起来是正确的工具。

请把链接放在第一个单词上好吗？

您在哪里要求提供 hudson 的链接？如果是这样，我添加了它，很好的电话:)

如果有人错过，Hudson 已被其原始开发人员分叉/重命名为 Jenkins。您现在最好选择 Jenkins，因为this question 可能会说服您。

【参考方案2】：

我们非常幸运地使用了以下组合：

Visual Studio（具体来说，使用 MSBuild.exe 命令行工具并将我们的解决方案文件传递给它。无需 msbuild 脚本） NAnt（比如比 MSBuild 更好的 XML 语法/任务库。还有 P4 src 控制操作的选项） CruiseControl.net - 用于监控/启动构建的内置 Web 仪表板。

CCNet 内置了通知器，可在构建成功/失败时发送电子邮件

关于理由：这减轻了开发人员进行手动构建的负担，并在很大程度上消除了人为错误。很难量化这种影响，但一旦你做到了，你就永远不会回头。拥有一个可重复的过程来构建和发布软件是至关重要的。我敢肯定，您曾经去过他们手工构建软件的地方，但它却在野外传播，只是让您的构建人员说“糟糕，我一定忘记包含那个新的 DLL！”

在硬件上：尽可能强大。更多功率/内存 = 更快的构建时间。如果您能负担得起，您将永远不会后悔拥有一台一流的构建机器，无论团队规模多么小。

占用空间：有助于拥有足够的硬盘空间。您可以制作您的 NAnt 脚本以在每次构建开始时删除中间文件，因此真正的问题是保留日志历史记录和旧的应用程序安装程序。我们有监控磁盘空间和发送警报的软件。然后我们手动清理驱动器。通常需要每 3-4 个月进行一次。

关于构建通知：这是内置在 CCNet 中的，但如果您要添加自动化测试作为附加步骤，那么从一开始就将其构建到项目中。一旦项目变大，就很难进行回拟合测试。那里有大量关于测试框架的信息（可能也有大量关于 SO 的信息），所以我将推迟命名任何特定工具。

【讨论】：

是的，我在 CC.NET 方面也有很好的经验 :)

很好的答案，除了硬件要求。他在夜间进行构建，所以我怀疑他是否关心编译和测试是否需要几个小时。我什至建议在他们已经拥有的硬件上的虚拟机中设置整个东西。

感谢您的提示。我将在我的理由中使用它。

我们在这里使用带有 NAnt/Subversion/CC.Net 的构建机器进行 C# 和 C++ 构建，它确实是一个很棒的工具，可以确保您没有破坏任何其他项目。它消除了在更改库时破坏另一个项目的很多恐惧，因为无论如何，如果它破坏了一切，您很快就会看到它

【参考方案3】：

在我以前的工作场所，我们使用TeamCity。它使用起来非常简单且功能强大。它可以免费使用，但有一些限制。 Dime Casts也有教程。我们没有使用 CruiseControl.NET 的原因是我们有很多小项目，在 CC.NET 中设置每个项目非常痛苦。我强烈推荐 TeamCity。总结一下，如果你是开源的，那么 CC.NET 是学习曲线稍高的老爹。如果您的预算允许，您肯定会选择 TeamCity 或查看免费版本。

【参考方案4】：

怎么样？看看 Carel Lotz 的 blog。

为什么？我能想到的原因有几个：

正确实施的工作构建意味着您的所有开发人员可以在构建为绿色时在他们的计算机上构建 正确实施的工作构建意味着您随时可以部署 正确实施的工作版本意味着您发布的任何内容都已访问您的源代码控制系统。 正确实施的工作版本意味着您可以尽早且经常地进行集成，从而降低集成风险。

Martin Fowler 关于Continuous Integration 的文章仍然是最终文本。看看吧！

【参考方案5】：

赞成的主要论点是，它会尽快提醒您构建损坏或测试失败，从而降低开发过程的成本。

整合多个开发人员的工作的问题是团队成长的主要危险。团队越大，就越难协调他们的工作并阻止他们互相干扰对方的更改。唯一好的解决方案是告诉他们“尽早并经常集成”，方法是在完成小单元工作（有时称为“故事”）时检查它们。

您应该在一天中每次签入时都重建构建机器。使用 Cruise Control，您可以在任务栏上看到一个图标，该图标会在构建中断时变为红色（甚至会与您对话！）。

然后，您应该每晚进行一次完整的干净构建，其中标记了源版本（给定一个唯一的构建号），您可以选择将其发布给您的利益相关者（产品经理、QA 人员）。这样一来，当报告错误时，它会针对已知的内部版本号（这非常重要）。

理想情况下，您应该有一个可以下载构建的内部站点，并有一个按钮可以单击以发布以前的夜间构建。

【讨论】：

很想听听反对者的理由！

我也会。这是对这个问题的一个很好的回答。我特别喜欢关于发布和版本控制的观点。

【参考方案6】：

只是想在 mjmarsh 所说的基础上有所建树，因为他奠定了良好的基础......

Visual Studio。 MSBuild 工作正常。 NAnt。 NantContrib。这将提供额外的任务，例如 Perforce 操作。 CruiseControl.net。这基本上又是您的“构建仪表板”。

以上所有内容（VS 除外）都是开源的，因此您无需考虑任何额外的许可。

正如 Earwicker 所说，尽早构建，经常构建。知道有什么东西坏了，然后你就可以生成一个可交付的东西，这对于及早发现东西很有用。

NAnt 还包括 nunit/nunit2 的任务，因此您实际上可以自动化您的单元测试。然后，您可以将样式表应用到结果中，并在 CruiseControl.net 提供的框架的帮助下，为每个构建提供可读、可打印的单元测试结果。

这同样适用于 ndoc 任务。为每个构建制作并提供您的文档。

您甚至可以使用 exec 任务来执行其他命令，例如，使用 InstallShield 生成 Windows 安装程序。

---

我们的想法是尽可能地自动化构建，因为人类会犯错误。在前面花费的时间是在路上节省的时间。人们不必通过构建过程来照看构建。确定构建的所有步骤，为每个任务创建 NAnt 脚本，并一个一个地构建您的 NAnt 脚本，直到您完全自动化整个构建过程。然后它还将您的所有构建放在一个地方，这有利于比较。 Build 426 中的某些问题在 Build 380 中运行良好？好吧，已经准备好测试的可交付成果了——拿起来测试一下。

【讨论】：

我忘记了 ndoc。文档是一个完整的“我们将不得不处理的另一个蜡球——感谢您的提醒。

【参考方案7】：

不需要许可证。 CruiseControl.net 是免费提供的，只需要构建 .NET sdk。 即使没有自动化单元测试，构建服务器仍然为构建版本提供受控环境。不再有“约翰通常在他的机器上构建，但他生病了。出于某种原因，我无法在我的机器上构建” 现在我在 Virtual PC 会话中设置了一个。 是的。构建需要转储到可访问的地方。开发版本应该打开调试。发布版本应该将其关闭。 多久由您决定。如果设置正确，您可以在每次签入后构建，开销将非常小。如果您有（或计划有）单元测试，这是一个好主意。 根据需要保留里程碑和版本。其他任何事情都取决于您构建的频率：持续？抛弃。日常的？保持一周的价值。每周？保留两个月的价值。

您的项目越大，您就越能看到自动构建机器的好处。

【参考方案8】：

一切都与构建的健康状况有关。这让你可以设置任何你想在构建中发生的事情。其中，您可以运行测试、静态分析和分析器。 当您最近处理应用程序的那部分时，问题的处理速度要快得多。如果您提交小的更改，那么它几乎会告诉您您在哪里破坏了它:)

这当然假设，您将其设置为在每次签入时构建（持续集成）。

它还有助于拉近 QA 和开发人员的距离。因为您可以设置功能测试来运行它，以及分析器和其他任何改进对开发团队的反馈的东西。这并不意味着每次签入都会运行功能测试（可能需要一段时间），而是您使用整个团队通用的工具设置构建/测试。我一直在自动化烟雾测试，所以在我的例子中，我们的合作更加密切。

【参考方案9】：

为什么： 10 年前，我们作为软件开发人员习惯于对某事进行第 n 级分析，得到文件（用人类语言编写）“签字”，然后开始编写代码。我们会进行单元测试、字符串测试，然后进行系统测试：系统第一次作为一个整体一起运行，有时是在我们签署文件几周或几个月后。只有到那时，我们才会发现我们在分析一切时的所有假设和误解。

持续集成和想法使您能够构建一个完整的（尽管最初非常简单）端到端的系统。随着时间的推移，系统功能会正交构建。每次您进行完整的构建时，您都在尽早且经常地进行系统测试。这意味着您可以尽早发现并修复错误和假设，而此时修复它们的成本最低。

如何： 至于怎么做，前段时间我在博客上写过：[Click Here]

超过 8 篇文章逐步介绍了如何在 Windows 环境中为 .NET 解决方案设置 Jenkins 服务器。

【讨论】：

虽然此链接可能会回答问题，但最好在此处包含答案的基本部分并提供链接以供参考。如果链接页面发生更改，仅链接的答案可能会失效。

这并没有提供问题的答案。要批评或要求作者澄清，请在他们的帖子下方发表评论 - 您可以随时评论自己的帖子，一旦您有足够的reputation，您就可以comment on any post。

根据反馈更新了我的评论。