mmr*_*mmr 144 c# build-automation continuous-integration hudson build
我正在与C#项目上的一个小型(4人)开发团队合作.我已经提议建立一个构建机器,它将对项目进行夜间构建和测试,因为我知道这是一件好事.麻烦的是,我们这里没有足够的预算,所以我必须证明费用是合理的.所以我想知道:
我意识到这是一个非常大的话题,我刚刚开始.我在这里找不到这个问题的副本,如果那里有一本书我应该得到,请告诉我.
编辑:我终于开始工作了!Hudson非常棒,FxCop表明我们认为实现的一些功能实际上是不完整的.我们还必须将安装程序类型从Old-And-Busted vdproj更改为New Hotness WiX.
基本上,对于那些正在关注的人,如果你可以从命令行运行你的构建,那么你可以把它放到哈德森.通过MSBuild从命令行运行构建本身就是一个很有用的练习,因为它会强制你的工具是最新的.
All*_*ice 147
更新:Jenkins是Hudson的最新版本.现在每个人都应该使用Jenkins.我将相应地更新链接.
Hudson是免费的,非常容易配置,可以在VM上轻松运行.
部分来自我的一个老帖子:
我们用它来
以下是Hudson支持的一些内置.net内容
此外,上帝禁止你使用视觉源安全,它也支持它.我建议你看看Redsolo关于使用Hudson构建.net项目的文章
你的问题
问:我需要什么样的工具/许可证？现在,我们使用Visual Studio和Smart Assembly来构建,并使用Perforce进行源代码控制.我是否需要其他东西,或者是否有相当于运行自动脚本的cron作业？
答:我刚安装了一个运行全新,修补,安装Windows服务器操作系统的VM的全新副本.所以你需要许可证来处理它.Hudson将自己安装为Windows服务并在端口8080上运行,您将配置您希望它扫描代码存储库以获取更新代码的频率,或者您可以告诉它在特定时间构建它.全部可通过浏览器配置.
问:除了迹象表明构建破坏之外,这究竟是什么？我应该在这个脚本运行的解决方案(sln文件)中设置测试项目,这样我可以测试特定的功能吗？目前我们有两次这样的测试,因为我们没有时间(或坦白地说,经验)来进行良好的单元测试.
答:您将在第一次构建失败或变得不稳定时收到电子邮件.如果单元测试失败,或者可以通过您设置的任何数量的标准将其标记为不稳定,则构建不稳定.当单元测试或构建失败时,您将通过电子邮件发送,它将告诉您失败的位置,原因和方式.通过我的配置,我们得到:
问:我需要什么样的硬件？
答: VM就足够了
问:一旦构建完成并经过测试,将这种构建放在ftp站点上还是有其他方式进行内部访问是一种常见的做法吗？我们的想法是这台机器进行构建,我们都去了它,但是如果必须的话,可以进行调试构建.
答: Hudson可以随心所欲地做任何事情,包括通过md5哈希进行ID,上传,复制,存档等等.它会自动执行此操作并为您提供构建工件的长期运行历史记录.
问:我们应该多久进行一次这种构建？
答:我们每小时都会轮询SVN,寻找代码更改,然后运行构建.Nightly是好的,但有点无价值的IMO,因为你昨天工作的东西在早上进入时不会在你脑海里清醒.
问: 如何管理空间？如果我们制作夜间版本,我们是否应该保留所有旧版本,或者在大约一周左右后开始抛弃它们？
答:这取决于你,经过这么长时间我将构建工件移动到长期存储或删除它们,但是我保留的文本文件/ xml文件中存储的所有数据,这让我存储更改日志,趋势图,服务器上的等等,消耗了很少的空间.此外,您可以将Hudson设置为仅保留一系列尾随的构件
问:还有什么我没看到的吗？
答:不,现在去哈德森,你不会失望的!
Mik*_*all 26
我们在以下组合中运气很好:
CCNet内置了通知程序,可在构建成功/失败时发送电子邮件
在理由上:这会减轻开发人员进行手动构建的负担,并且可以将人为错误排除在外.很难量化这种效果,但一旦你这样做,你将永远不会回去.拥有可重复的过程来构建和发布软件是至关重要的.我确信你已经成为他们手工构建软件的地方,它会在野外出现,只是为了让你的构建人员说"哎呀,我一定忘记包含那个新的DLL!"
在硬件上:尽可能强大.更多功率/内存=更快的构建时间.如果你能负担得起,无论团队多么小,你都不会后悔获得一流的制造机器.
在空间:有助于拥有足够的硬盘空间.您可以制作NAnt脚本以在每次构建开始时删除中间文件,因此真正的问题是保留日志历史记录和旧应用程序安装程序.我们有监控磁盘空间并发送警报的软件.然后我们手动清理驱动器.通常需要每3-4个月完成一次.
关于构建通知:这是内置于CCNet的,但如果您要将自动化测试作为附加步骤添加,则从一开始就将其构建到项目中.一旦项目变大,就很难回溯测试.有很多关于测试框架的信息(可能还有关于SO的大量信息),因此我将推迟命名任何特定工具.
Jef*_*eff 11
在我之前的工作场所,我们使用了TeamCity.它使用起来非常简单和强大.它可以免费使用,但有一些限制.还有一个关于Dime Casts的教程.我们没有使用CruiseControl.NET的原因是我们有很多小项目,在CC.NET中设置每个项目都非常痛苦.我强烈推荐TeamCity.总结一下,如果你是开源软件,那么CC.NET就是那个学习曲线略高的大爸爸.如果您的预算允许您使用TeamCity或查看免费版本.
支持的主要理由是,它会通过提醒您尽快建立破坏的构建或测试失败来降低开发过程的成本.
整合多个开发人员的工作的问题是团队成长的主要危险.团队越大,就越难协调他们的工作并阻止他们搞乱彼此的变化.唯一好的解决方案是告诉他们"尽早和经常融合",通过检查完成后的小工作单元(有时称为"故事").
您应该在一天中进行一些检查时使构建机器重建.使用Cruise Control,您可以在任务栏上获得一个图标,当构建中断时,该图标变为红色(甚至可以与您交谈!).
然后,您应该进行夜间完全清理构建,其中标记源版本(给定唯一的构建号),您可以选择将其发布给您的利益相关者(产品经理,QA人员).这是因为当报告错误时,它是针对已知的构建号(这是非常重要的).
理想情况下,您应该有一个内部站点,可以下载构建,并有一个按钮,您可以单击以发布以前的每晚构建.
试着建立一下mjmarsh说的话,因为他奠定了坚实的基础......
以上所有(除VS之外)都是开源的,因此您不会考虑任何其他许可.
正如Earwicker所说,早建,经常建造.知道某些事情已经破裂了,你可以制作一个可交付成果对于早期捕捉东西很有用.
NAnt还包括nunit/nunit2的任务,因此您可以实际自动化单元测试.然后,您可以将样式表应用于结果,并在CruiseControl.net提供的框架的帮助下,为每个构建提供可读的,可打印的单元测试结果.
这同样适用于ndoc任务.为每个构建生成并提供您的文档.
您甚至可以使用exec任务执行其他命令,例如,使用InstallShield生成Windows Installer.
我们的想法是尽可能地自动化构建,因为人类会犯错误.预先花费的时间是在路上节省的时间.人们不必通过构建过程来照看构建.确定构建的所有步骤,为每个任务创建NAnt脚本,并逐个构建您的NAnt脚本,直到您完全自动化整个构建过程.然后它还将所有构建放在一个位置,这有利于比较.Build 426中的一些东西在Build 380中运行良好吗？好吧,有可交付的产品可供测试 - 抓住它们并进行测试.