持续集成:PowerShell与CI服务器(CC.NET或Hudson)

pet*_*don 11 cruisecontrol.net powershell continuous-integration unit-testing hudson

所以,我和朋友一直在讨论持续集成和bat/powershell脚本与CruiseControl.Net或Hudson等CI服务器.

以下powershell伪脚本适用于从SVN更新,使用msbuild构建,部署/复制,更新应用程序中的构建/修订号以及发生故障构建的电子邮件.下一步是添加对MSTest的调用,并在未成功时通过电子邮件发送结果.

  1. svn更新
  2. msbuild> build_deploy_development_out_msbuild
  3. ([xml](svn info --xml)).info.entry.commit.revision + [char] 13 + [char] 10 +(echo%date %% time%)> build_revision_number.html
  4. $ linenumber = Select-String build_deploy_development_out_msbuild -pattern"Build Failed"| 选择对象线号
  5. $ smtp = New-Object System.Net.Mail.SMTPClient -ArgumentList localhost | 如果($ linenumber> 0)$ smtp.Send("来自:电子邮件","收件人:电子邮件","构建失败","构建失败......有人必须死!")

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

我还没有经历过维护费用.我希望得到其他人对你自己的shell脚本与CruiseControl.Net或Hudson的意见.请注意,我没有CI服务器的经验,因此这个问题,所以请不要将其视为对CI服务器的批评; 我根本不知道最好的答案,并认为我会问社区.

最好的祝愿!皮特戈登

Pet*_*ete 9

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

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

其中一些可能不是你现在需要的东西,但你确定它们不是你将来可能需要的东西吗?


Vla*_*mir 3

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

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

Hudson 为您的脚本提供了良好的可见性(所有内容都可以在首页上看到),并且它们是不言自明的。通常使用 bash 脚本,您需要编写一个自述文件(没有人阅读)并记住它们的位置。