所以，我和朋友一直在讨论持续集成和bat / powershell脚本与CruiseControl.Net或Hudson等CI服务器。
以下powershell伪脚本适用于从SVN更新，使用msbuild构建，部署/复制，更新应用程序中的构建/修订号以及发生故障构建的电子邮件。下一步是在未成功时添加对MSTest的调用和电子邮件结果。
这让我想到了CI服务器的价值问题，当你可以使用项目的特定工具（构建工具，源代码控制，单元测试）编写自己的shell脚本来实现相同的目标时（即msbuild，nant，svn，git，nunit，mstest等。）
到目前为止，我还没有经历过维护费用。我希望得到其他人对你自己的shell脚本与CruiseControl.Net或Hudson的意见。请注意，我没有CI服务器的经验，因此这个问题，所以请不要将其视为对CI服务器的批评;我根本不知道最好的答案，并认为我会问社区。
祝福！ 皮特戈登
答案 0 :(得分：9)
CI服务器为您提供了几个优势：
其中一些可能不是您需要的东西现在，但您确定它们不是您将来可能需要的东西吗？
答案 1 :(得分：3)
我几周前安装了Hudson来替换当前的CruiseControl服务器。我在Hudson看到的最大优势是几乎任何人都可以使用它，而使用CruiseControl（或批处理文件）启动参数化构建对于很多人来说仍然是可怕的。
通常我倾向于使用Ant编写所有构建脚本（因为它是可移植的），插入几个参数并从Hudson调用它们。
Hudson为您的脚本提供了很好的可见性（一切都可以在首页看到），并且它们是自我解释的。通常使用bash脚本，您需要编写自述文件（没有人阅读）并记住它们的位置。
答案 2 :(得分：3)
......或两者都有。 Ayende（Rhino Mocks的创造者）最近已经做到了。他使用PowerShell编写了一个CI服务器。也许this为您的讨论提供了新的见解。
答案 3 :(得分：1)
一年来，我一直试图维护自定义编写的python脚本来完成基本的CI工作：通过电子邮件收到提交通知，检查和构建内容，发回责任和恭喜，然后发布这是我的团队中的其他人使用的，结果是raaaather无法监控，网络访问等等。
然后我潜入了buildbot并发现它真的很美。我在几天内建立了基本相同的过程。构建脚本是一个真正的python对象，可以在主服务器上自定义，从那里传输到从服务器并在那里执行。建立在扭曲的框架之上，这是很多开箱即用的东西;）
Web UI虽然足够，但却很简约。
嗯，这也是未发表的，虽然我这次接近它了％）
答案 4 :(得分：1)
以下是关于通过Powershell脚本的CI服务器的想法
如果您必须为不同的环境和团队项目维护大量构建，那么CI服务器就是最佳选择。除此之外，简单的PowerShell脚本足以满足小型项目的需求。项目增长后，您可以将现有的PowerShell脚本连接到CI服务器。