問題＃1〜＃4的Joel Test在我看來都對開發工具的使用和支持系統到位開發商更高：工具，以幫助一家小商店在比分上「喬爾測試」
我只是很好奇沒有大型銀行賬戶的小型開發商店使用哪些免費/便宜（但是很好）的工具來獲得這些問題的積極答案。
對於源代碼控制，我知道Subversion是一個很好的解決方案，如果你是一個人的店，你甚至可以使用SourceGear的Vault。
我對我的大型項目使用NAnt，但尚未建立腳本來構建我的安裝程序以及將混淆工具作爲一個步驟運行。還有其他建議嗎？
如果您只需一步就可以爲建築物回答「是」，我認爲創建日常構建會很容易，但是您會推薦哪些工具來自動執行這些日常構建？
對於一個或兩個人的團隊，它已經在SO上進行了討論，您可以使用FogBugz On Demand，但是對於小團隊還存在哪些其他的bug跟蹤解決方案？
相對便宜的一個好問題跟蹤器是axoSoft OnTime。我在使用MS TFS之前使用了它幾年。
Nant和CruiseControl是我的環境的主食。
我不認爲你真的需要混淆。淨更多（see another response）
我不會考慮保險櫃，SVN真的是目前市場領導者（和免費）。 Git看起來非常有前途，但目前只有命令行才具有陡峭的學習曲線。
的MSBuild節拍惡性對於.NET 2或3.5
CC.Net優異。
我的工程堆棧：
毫無疑問，這些選擇會受到我的開發堆棧的影響，這些開發堆棧通常包括Ruby，Rails，SQLite，Firefox和OSX。
我沒有任何工具可以建議，但我確實有關於每日構建的建議。儘管我們沒有每日構建，但我始終對這個問題回答「是」。相反，我們每次有人提交時都會進行構建。因此，我們幾乎立即發現任何問題。如果我們的任何項目都有足夠的LOC，那麼建築需要的不僅僅是微不足道的時間，而且這樣做也會逐步降低日常構建的方向。
你重建所有（可以）取決於提交的代碼？ 在某些情況下（更改基本組件之一）可能導致重建整個應用程序。你如何處理建立一次提交的時間？ 謝謝。 – TcKs 2009-06-08 12:04:45
您可能需要查看finding an alternative to Team System的現有我的問題。那裏還有很多建議。
檢查出使用的MSBuild，CruiseControl.NET，FxCop的，NUnit的，NCover和Subversion持續集成這些文章...
我目前使用SVN，但我通常有一個很多或簽到服務器上的網絡驅動器簽出問題。這往往是鎖定問題，需要大量捕魚來修復。這可能是使用WebDav訪問方法，可以緩解一些問題，但我還沒有嘗試過。
Bugzilla，Trac或Fogbugz中的任何一個都可以幫助您進行錯誤跟蹤，並且每個都提供導出功能，所以您以後可以隨時改變主意。另外，如果你能得到你的團隊完全購買，時間管理軟件也可以得心應手後驗屍等（如果大家都積極地充分參與
我的首選堆：
1）顛覆。我對分佈式源代碼控制很感興趣，但還沒有機會嘗試任何憤怒。對於一個集中的解決方案svn是堅如磐石的。
2）Ant。 Maven在工作時使用是一種樂趣，但作爲一名老螞蟻黑客，我發現一旦出現問題，Maven很難遵循。
3）Hudson。目前尚未提及，但絕對值得研究。令人難以置信的可用和積極維護的工具。 PreviousLy我們爲Anthill Pro付出了代價，它看起來很老舊，每次修理都很痛苦。
4）我們支付jira。不便宜，但比我們看到的開源選項更有用，而且非常靈活。
我的幾個音節;-)
一個人一定要使用某種版本控制，其中的開發人員可以輕鬆地創建私有分支，然後將其私有分支並將其擠入主分支中的單個提交。這樣，與組織相對的個人開發人員就可以從版本控制中獲益，而不會污染任何其他人的代碼（並放慢他們的工作），並且提交失敗。
此功能是我喜歡的git。我認爲這只是真正存在於分佈式版本控制系統中;但是，使用DVCS並不意味着您實際上必須進行分佈式開發。
關於一步構建，make是默認的構建工具，它對大多數任務來說工作得很好。除非你有充分的理由不這樣做，否則我會這樣做。
你想要每日構建，把生成命令放在你的cron.daily中。如果需要的話，設置一個procmail掛鉤來處理來自cron的郵件。
對於錯誤跟蹤，請使用$(apt-cache search bug tracking)。基本上，只要它在盒子上說「bug跟蹤器」，並且你知道其他人正在使用它，它可能會正常工作。常客中包括bugzilla，mantis和trac。
如果你希望它是.NET和自由，而不是自由ish，然後是BugTracker.NET而不是雙子座。有很好的Subversion集成。 – 2008-09-27 04:15:05