构建过程-使用什么?

作为一个项目,南特已经死了,或者正在进行生命支持(上一个版本是0.86 beta 1,两年前)。它基本上被msbuild的发布缩短了。Nant很不错,我想msbuild也不错,但是我越来越喜欢用一种语言而不是一些基于XML的过程性东西来编写代码。在基于XML的构建框架中,调试体验非常糟糕,您最终会通过在C中嵌入“脚本”来作弊,这会破坏声明而不是编程的目的。就这一点而言,和XSLT一样令人伤心。

一些好的无XML构建框架:

• 耙 http://rake.rubyforge.org/ (基于Ruby)非常好,存在一些特定于.NET的任务,我认为IronRuby现在运行它。
• 清酒 http://code.google.com/p/psake/ (基于PowerShell)-非常有希望
• 伪造的 http://code.google.com/p/fake/ 对于热爱F的冒险精神#

我仍然使用msbuild,因为它是csproj文件的格式,但是对于特定的东西,我不喜欢用XML构建逻辑(没有自定义的msbuild任务)。

不要使用C来构建脚本,因为您不想在对其进行更改时编译它。

如果您计划使用PowerShell,请查看 PSake .

如果您是XML友好的,那么使用msbuild或nant。也许吧 those build scripts 对你很有价值。msbuild有一个优点:ctrl+f5在Visual Studio中生成此脚本。

我一直在慢慢地移动到Rake,因为它更好,Ruby是编程语言(这意味着你可以做任何事情): I blogged about how nice it could be, but you have to translate it or look at code only . 如果你喜欢,那么你可能想看看 full script 和 dependencies .

Good book about continuous integration is from Paul Duvall, Steve Matyas and Andrew Glover (Continuous Integration: Improving Software Quality and Reducing Risk).

在一天结束时,msbuild和nant任务都可以shell到命令行,因此最终它们 能够 支持非微软产品。

我个人喜欢msbuild,并且会让一个像ccnet的teamcity这样的构建服务器进行构建和部署等,这是难以置信的灵活性。

我看不出为什么不在PowerShell中执行一个简单的构建过程。

我的沙盒项目使用以下内容:

#Types
Add-Type -Path D:\Code\OSLib\SharpSvn-x64\SharpSvn.dll

#Tools
$svn = New-Object SharpSvn.SvnClient
$msbuild = 'D:\Windows\Microsoft.NET\Framework64\v4.0.21006\msbuild'
$mstest = 'D:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\mstest'

#Sandbox
$sandbox = New-Object SharpSvn.SvnUriTarget -argumentlist "http://dan:password@sevenmagoo:81/svn/sandbox/trunk/"
$workingdir = 'D:\Code\sandbox'
$builddir = 'D:\Build\sandbox'
$solution = $builddir + '\sandbox.sln'
$tests = '/testcontainer:D:\Build\sandbox\sandbox.Tests\bin\Debug\sandbox.Tests.dll'

function sandbox() { ii D:\Code\sandbox\sandbox.sln }
function build()
{   
     echo 'Empty build directory and recreate'
    rm -r -Force $builddir | out-null;
    md $builddir  | out-null; 

    echo 'Checkout successful? '
    $svn.Checkout($sandbox, $builddir);;


    echo 'Building'
    .$msbuild $solution /nologo;

    echo 'Testing'
    .$mstest $tests /nologo;;  
}

Ayende Rahien也做过类似的事情, here .

希望能有所帮助,

仁慈,

丹

最大的问题是构建脚本的维护。如果您看到您的项目或环境保持一定的静态,那么就没有理由不编写自己的构建、打包和部署脚本。

事情通常会比你的项目复杂得多。msbuild、nant和其他(商业)产品提供的一些优势是对与公共服务或概念(例如,压缩文件)集成的预烘焙支持,而且将其加入构建过程所花费的时间要少得多。

只要你能合理地预测你的自动化需求,就会有成本(实际的,或是工作方面的),朝着对你的环境有意义的方向发展。

我为你认为最适合的方法增加了一些考虑 here 它们可能有助于确定自动化的范围。

如果您打算继续成为一个“一人行”,并且您的项目通常很小,那么您可能可以通过滚动自己的构建系统来实现。我仍然建议不要这样做,因为在你的简历中有一个关于常用构建环境的经验是一件好事。

我编写了一个定制的构建系统,大约五年前我们在工作中使用它来处理一些相当复杂的、多目标的构建。我们从2003年开始使用它,并继续使用它。但是,我一直试图将它移向Ant,甚至出于以下原因:

1. 我写的构建系统运行在Windows上,我们需要其他平台。它可以被重写以便在其他地方相当容易地运行,但是过程管理代码很难轻松移植。
2. 集成到 CI 如果您使用的是完全自定义的环境,那么环境就是一种痛苦。
3. 为不同的 SCM 科技是一只熊。到目前为止,我们需要对Visual SourceSafe、Subversion和Performance的支持。
4. 扩展和维护它需要很多工作 “不增加客户价值” .

现在,我们的环境比大多数环境要复杂一点,因为我们进行嵌入式系统开发,所以在Windows上使用两个或三个不同的工具链构建单个产品构建,通过ssh为仅Linux的目标shell到Linux机器,以及 psexec 到远程Windows计算机使用节点锁定的编译器。回顾过去并认为我们从单个批处理文件开始的构建系统是用Perl重写的,以适应声明性语句和编程语言语句的混合,然后用类似于Ant的XML声明性样式重新编写,从而将批处理或shell解包。现在我正在考虑用蚂蚁+马文+常春藤或者类似的链条来取代所有这些。

滚动我自己的构建系统对当时的我来说是正确的决定,因为我们是一家非常小的商店,主要基于命令行工具进行构建,当时没有大量可用的工具。不过,今天我建议您仔细研究一下可用的工具。毕竟,编写自己的构建系统意味着您将花费时间和金钱来编写和维护它,而不是编写 生产代码 .

今天有很多工具可以完成这项任务,几乎可以处理任何你能想到的扭曲的想法。我认为花在学习一个现有系统和扩展它以满足您的需求上的时间可能更有价值。我觉得写蚂蚁任务的经历很有趣。总的来说,这是一次很好的学习经历,尽管我是在一份使用Ant和CruiseControl发布文档的合同工作中完成的。

有一件事我到目前为止还没有看到太多提到:依赖/重建管理。一个良好的建筑体系 make )将为您处理这个问题,如果您构建自己的构建系统,那么您将执行以下两项操作之一:

• 经常重建一切(或者至少比你需要的更多)
• 自己重新实现依赖项跟踪和更新逻辑

从这个角度来看,我会在推出你自己的解决方案之前考虑很久和努力。

然而,听到南特快死了,我很难过;虽然它也有疣,但蚂蚁是一个合理而灵活的构建系统。