持续集成：PowerShell 与 CI 服务器（CC.NET 或 Hudson）答案

【问题标题】：Continuous Integration: PowerShell vs. CI Server (CC.NET or Hudson)持续集成：PowerShell 与 CI 服务器（CC.NET 或 Hudson）
【发布时间】：2010-12-06 10:10:15
【问题描述】：

所以，我和一个朋友一直在讨论持续集成和 bat/powershell 脚本与 CI 服务器（如 CruiseControl.Net 或 Hudson）的对比。

以下 powershell 伪脚本可用于从 SVN 更新、使用 msbuild 构建、部署/复制、更新应用程序中的构建/修订号，以及在构建失败时发送电子邮件。下一步是在不成功时添加对 MSTest 的调用和电子邮件结果。

svn 更新
msbuild > build_deploy_development_out_msbuild
([xml](svn info --xml)).info.entry.commit.revision + [char]13 + [char]10 + (echo %date% %time%) > build_revision_number.html
$linenumber = 选择字符串 build_deploy_development_out_msbuild -pattern "构建失败" |选择对象行号
$smtp = 新对象 System.Net.Mail.SMTPClient -ArgumentList localhost | if($linenumber > 0) $smtp.Send("From:Email","To:Email", "build failed", "build failed...some one must die!")

这让我想到了 CI 服务器的价值问题，当您可以编写自己的 shell 脚本来完成相同的目标时，使用项目的特定工具（构建工具、源代码控制、单元测试）（即msbuild、nant、svn、git、nunit、mstest 等）

我还没有经历过维护费用。我想在滚动您自己的 shell 脚本与 CruiseControl.Net 或 Hudson 时获得其他人的意见。请注意，我没有使用 CI 服务器的经验，所以这个问题，所以请不要认为这是对 CI 服务器的批评；我根本不知道最佳答案，我想我会问社区。p>

祝你好运！皮特·戈登

【问题讨论】：

这应该是社区wiki，因为没有明确的答案
为什么还要列出 CC.NET 或 Hudson？这似乎是一个 Powershell VS CI 问题。为什么是语义？

标签： unit-testing powershell continuous-integration cruisecontrol.net hudson

【解决方案1】：

CI 服务器为您提供了几个优势：

Web 访问，通常具有与现有身份验证机制集成的能力（请参阅 Hudson 的 ActiveDirectory/LDAP 支持）
现有大量支持单元测试、zip 存档创建等。
Hudson（和其他人）支持从属构建节点，用于执行分布式 CI 任务。
无需自己维护。

其中一些可能不是您现在需要的东西，但您确定它们不是您将来可能需要的东西吗？

【讨论】：

希望看到有关人们使用这些类型功能的民意调查。我不是 100% 有信心我了解所有这些。它确实让我对 powershell 中的 zip 归档感到好奇，我发现了这个...tfl09.blogspot.com/2008/12/zip-files-with-powershell.html 谢谢！
我已经使用了其中的一些功能，并构建了一些临时 Hudson 插件来解决一些项目特定的需求。 Hudson 最重要的方面是它是一个不断增长的项目，插件数量不断增加。
如何使用 Powershell 执行并发构建？您将如何管理版本控制、部署和代码覆盖率报告？为什么要重新发明轮子？

【解决方案2】：

几周前我安装了 Hudson 来替换当前的 CruiseControl 服务器。我在 Hudson 看到的最大优势是几乎任何人都可以使用它，而使用 CruiseControl（或批处理文件）启动参数化构建对很多人来说仍然很可怕。

通常我倾向于使用 Ant 编写所有构建脚本（因为它是可移植的），插入几个参数并从 Hudson 调用它们。

Hudson 使您的脚本具有很好的可见性（所有内容都可以在首页上看到），而且它们是不言自明的。通常使用 bash 脚本，您需要编写自述文件（没有人阅读）并记住它们的位置。

【讨论】：

【解决方案3】：

... 或者两者兼而有之。 Ayende（Rhino Mocks 的创建者）最近做到了这一点。他使用 PowerShell 编写了一个 CI 服务器。也许this 为您的讨论提供了新的见解。

【讨论】：

【解决方案4】：

一年来，我一直在尝试维护自定义编写的 python 脚本来完成基本的 CI 工作：通过电子邮件接收提交通知、签出和构建内容、发回责备和祝贺，然后是发布这个供我团队中的其他人使用，结果证明如果没有监控、网络访问等，它就无法使用。

然后我潜入 buildbot 并发现它真的很漂亮。我已经在几天内设置了基本相同的过程。构建脚本是一个真正的 python 对象，可以在主服务器上自定义，从那里它被转移到从服务器并在那里执行。建立在扭曲的框架上，有很多开箱即用的东西;)

Web UI 是简约的，但足够了。

嗯，这也是未发表的，虽然这次我已经接近了 %)

【讨论】：

【解决方案5】：

以下是我对基于 Powershell 脚本的 CI 服务器的看法

高度可配置插件可用于所有不同类型的版本控制、通知和测试。
日志这些维护得很好。失败和成功的构建日志触手可及。
调度您可以设置各种调度，包括基于其他成功构建的triggerring
安全性您可以将不同的组设置为能够执行、仅查看或设置为查看某些项目
可见性您可以针对不同的受众使用网络仪表板或 cctray。
可扩展性。可在需要时轻松扩展。

如果您必须为不同的环境和团队项目维护大量构建，那么 CI Server 是您的最佳选择。除此之外，对于小型项目来说，一个简单的 PowerShell 脚本就足够了。一旦项目增长，您可以将现有的 PowerShell 脚本连接到 CI 服务器。

【讨论】：