構建過程 - 使用什麼？

我正在考慮使用PowerShell和/或C＃編寫我自己的交付代碼，可能會對NAnt或MSBuild進行脫殼。構建過程 - 使用什麼？

我爲什麼要不走這條路？與使用NAnt或MSBuild相比，這是否非常困難？
任何好的，現代的書可以幫助嗎？
有什麼更好的點子？

背景（附註：這是一個宗教問題，對於一些沒有侮辱之意。）：

一人店，多探索項目。就像我們大多數人一樣 - 現在是windows和ASP.Net。考慮到移動和雲。

我開始插手NAnt，並試圖按照Expert .Net Delivery Using NAnt and CruiseControl.Net。「交付」的整個問題都被放在冰上，現在是時候「解凍」了。但是，我不確定要走哪條路。據我所知：

NAnt正在顯示其年齡。這很笨拙：比現代的OO語言（如C＃）更難以理解和維護。即使在我遵循這本書之後，在一個神祕的環境中工作似乎很奇怪，在這個環境中，您要執行的是XML，並且循環和繼承（就像我在「冰河世紀」之前記得的那樣）是難以實現的。

MSBuid是MS特定的。我甚至不確定它是否會支持非MS環境。團隊基礎服務器很昂貴。

即便如此，它們似乎都提供了價值，因爲在我的SO搜索中我沒有聽到任何人使用他們自己的定製軟件。但是，我不明白爲什麼不使用C＃，並根據需要調用NAnt和/或MSBuild任務。

SO - NAnt Vs. MSBuild

我的建議剛好相反 - 避免的MSBuild像瘟疫。 NANT遠遠更容易設置您的版本進行自動測試，部署到多個生產環境，與巡航控制集成入門環境，與源代碼控制集成。我們已經經歷了TFS/MSBuild（使用TFSDeployer，自定義PowerShell腳本等）的巨大痛苦，以使它能夠做到我們用NANT開箱即可完成的任務。不要浪費你的時間。

SO - NAnt vs. scripts：

還有更多建立一個產品不僅僅是編譯它。由於這些工具（及其擴展）提供的功能，諸如創建安裝，更新版本號，創建託管，分發最終包等的任務可能會更容易。雖然你可以做這一切定期腳本，使用惡性或MSBuild的給你一個堅實的框架，這樣做的所有

來源

2009-11-14 Avi

謝謝大家的驚人答案 - 這需要一點消化，但我真的覺得我剛剛有一個偉大的顧問會議。我希望我能「接受」你的答案！非常感謝SO這樣一個偉大的平臺 - 無論是在技術上還是在社交上。 – Avi 2009-11-14 21:48:25

楠作爲一個項目是死的，或者生命支持（最後版本是0.86 Beta 1中，前兩年）。它基本上被MSBuild的發佈所縮短。 NAnt很好，MSBuild沒問題，但我覺得越來越受歡迎，可以用語言來編寫代碼，而不是一些基於XML的程序性東西。使用基於XML的構建框架時，調試體驗非常糟糕，並且通過在c＃中嵌入「腳本」而最終導致作弊，這違背了程序化聲明的目的。就此而言，與XSLT一樣悲慘的故事。

一些不錯的免費XML的構建框架：

耙http://rake.rubyforge.org/（基於Ruby）相當不錯的一些.NET具體任務存在的，我覺得現在的IronRuby運行它。
PSake http://code.google.com/p/psake/（PowerShell的基礎） - 非常有前途的
假http://code.google.com/p/fake/誰愛F＃冒險的頭腦

我仍然使用的MSBuild，因爲它的的csproj文件的格式，但對於具體的東西我順構建邏輯在XML中（沒有自定義的MSBuild任務）。

來源

2009-11-14 11:44:14

NAnt可能不會主動維護，但上一個版本可以正常工作。我發現它比編寫一個自定義的MSBuild腳本更容易使用。爲了構建Visual Studio解決方案/項目，我只是將shell（exec）從NAnt中移出到MSBuild。 – TrueWill 2009-11-14 16:32:19

是的，它仍然有效，但延長它是痛苦的，nantcontrib有一段時間flatlined。構建系統需要的是明智的依賴關係管理，大量的自定義任務，簡單的調試和易擴展性。 NAnt只提供前兩個功能，而自定義任務有時會有點片面。但是如果你有一個Nant腳本的工作設置，保持原樣就可以了。 – 2009-11-14 17:00:29

NAnt *正在積極開發，請參閱sourceforge中的活動日誌：http://sourceforge.net/projects/nant/develop – 2010-11-07 15:14:32

我看不出有什麼理由不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:[email protected]: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。

希望幫助，

善良，

丹

來源

2009-11-14 10:27:43

使用PowerShell腳本包裝MSBuild任務的重點是什麼？只需使用MSBuild任務（大量定製的MSBuild任務）並直接調用MSBuild。 – 2009-11-14 11:11:31

我之所以寫它，是因爲我總是打開一個Powershell窗口，並希望能夠根據命令進行構建，並在不打開工作室的情況下運行項目單元測試。善良，丹 – 2009-11-14 11:21:31

最大的問題是構建腳本的維護。如果你看到你的項目或環境保持一定的靜態，那麼沒有理由不寫你自己的構建，打包和部署腳本。

事情通常變得更復雜，因爲你的項目。 MSBuild，nAnt和其他（商業）產品提供的一些優勢是預先支持與常用服務或概念（比如說壓縮文件）的集成，並且將其用於構建過程的時間要少得多。

還有的將是成本（實際或在工作方面），所以只要你能合理地預測你的自動化需求，進去是有道理爲您的環境的方向。

我添加了什麼方法，你找到最適合here他們可能在確定自動化的範圍幫助一些注意事項。

來源

2009-11-14 10:41:48 RobS

不要將C＃用於構建腳本，因爲您不希望在對其進行更改時對其進行編譯。

如果您打算使用PowerShell，然後拿上PSake看看。

如果你是XML友好的，那麼去MSBuild或NAnt。也許those build scripts對你很有價值。 MSBuild有一個優點：Ctrl + F5在Visual Studio中構建此腳本。

我一直在慢慢地移動到耙，因爲它是更好，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).

來源

2009-11-14 11:09:53

在一天結束的時候，雙方的MSBuild和楠任務可以掏出來的命令行，所以最終他們能支持非MS的東西。

我贊成MSBuild的個人，又會令像CCNET中的TeamCity構建服務器做構建和部署等，這是令人難以置信的靈活性。

來源

2009-11-14 11:13:59

爲TeamCity +1。我們在工作中開始使用CC.NET，並轉而使用TeamCity，以便維護和增加功能。我們仍然在幕後使用NAnt，但它需要比CC.NET少得多。 http://www.jetbrains.com/teamcity/我仍然很難看到任何人都可以更喜歡寫一個MSBuild腳本到NAnt，但前者似乎是後者的笨拙克隆。 – TrueWill 2009-11-14 16:38:20

這裏有一大堆自定義的MSBuild任務，請參閱MSBuild社區任務，Sdc任務和Microsoft MSBuild擴展包等等。實現你自己的任務是完全和完全微不足道的 - 從任務繼承，並實現Execute（）方法。我覺得這是一個輕而易舉的事情。 – 2009-11-14 17:31:44

如果您打算繼續成爲「單人店鋪」，而且您的項目一般很小，那麼您可以通過滾動自己的構建系統。我仍然建議不要這樣做，因爲具有常用構建環境的經驗對您的簡歷而言是件好事。

我寫了一個自定義構建系統，我們在五年前使用它來處理一些相當複雜的多目標構建。自2003年以來我們一直在使用它，並繼續使用它。不過，我一直在試圖將其移向螞蟻甚至使，原因如下：

，我寫在Windows上運行的構建系統，我們有必要對其他平臺。它可以被重寫成很容易在其他地方運行，但是流程管理代碼很難輕鬆移植。
如果您使用的是完全自定義的環境，則整合到CI環境中會很痛苦。
增加對不同SCM技術的支持是一個熊。到目前爲止，我們需要支持Visual SourceSafe，Subversion和Perforce。
擴展和維護「增加了客戶價值」很多工作。

現在我們的環境是一個多一點最複雜的，因爲我們做的嵌入式系統開發的，所以它不是罕見的單品打造建立在Windows上兩個或三個不同的工具鏈，掏出到Linux機器通過ssh訪問僅限Linux的目標，並通過psexec發送到遠程Windows機器以利用節點鎖定編譯器。回想起來，我們認爲我們已經開始使用單個批處理文件的構建系統是用Perl重寫的，以適應聲明性語句和編程語言語句的混合，然後再用類似Ant的XML聲明風格，批量或外殼。現在我正在考慮用Ant + Maven + Ivy或其他類似的鏈代替所有這些。

由於我們當時是一家非常小的商店，建立的主要基於命令行工具，當時沒有多種工具可供使用，所以自己構建系統對我來說是正確的決定。。然而，今天，我會建議對可用工具進行認真和嚴格的考察。畢竟，編寫自己的構建系統意味着您將花時間和金錢編寫並維護它，而不是編寫生產代碼。

今天的任務有很多工具可以處理幾乎所有你可以想到的扭曲想法。我認爲學習現有系統並將其擴展以滿足您的需求的時間可能更值得。我發現編寫Ant任務的經驗非常有趣。總的來說，即使我在使用Ant和CruiseControl發佈文檔的合同工作上完成這項工作，這也是一次很好的學習體驗。

來源

2009-11-14 13:33:30

目前爲止我還沒有看到太多提及的一件事：依賴/重建管理。好身材系統（甚至古老的make）將處理這個給你，如果你建立你正在做的兩件事情你自己構建系統：

頻繁重建一切（或比你至少需要更多到）
重新實現依賴跟蹤和更新自己的邏輯

從這個角度來看，我會覺得漫長而艱難的滾動自己的解決方案之前。

雖然聽到NAnt正在死亡，雖然它有它的疣的份額，螞蟻是一個合理和靈活的構建系統。

來源

2009-11-14 13:54:52

構建過程 - 使用什麼？

回答

相關問題