我认为 Joel Test 上的问题 #1 到问题 #4 都是关于开发的正在使用的工具以及为开发人员提供的支持系统：
- 您使用源代码控制吗？
- 你能一步完成构建吗？
- 您进行日常构建吗？
- 你有错误数据库吗？
我只是好奇对于没有大量银行账户的小型开发商店来说，有哪些免费/便宜（但很好）的工具可以用来对这些问题做出积极的回答。
对于源代码控制，我知道 Subversion 是一个很好的解决方案，如果您是一家单人商店，您甚至可以使用 SourceGear 的
我将 NAnt 用于较大的项目，但尚未设置脚本来构建我的安装程序以及将混淆工具全部作为一个步骤运行。 还有其他建议吗？
如果您可以一步回答“是”，我认为创建每日构建会很容易，但是您会推荐哪些工具来自动化这些每日构建？
对于一两个人的团队，已经在 SO 上讨论过您可以使用 FogBugz On Demand，但是对于小型团队还有哪些其他错误跟踪解决方案？
Questions #1 through #4 on the Joel Test in my opinion are all about the development tools being used and the support system in place for developers:
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
I'm just curious what free/cheap (but good) tools exist for the small development shops that don't have large bank accounts to use to achieve a positive answer on these questions.
For source control I know Subversion is a great solution, and if you are a one man shop you could even use SourceGear's Vault.
I use NAnt for my larger projects, but have yet to set up a script to build my installers as well as running the obfusication tools all as a single step. Any other suggestions?
If you can answer yes to the building in a single step, I think creating daily builds would be easy, but what tools would you recommend for automating those daily builds?
For a one or two man team, it's already been discussed on SO that you can use FogBugz On Demand, but what other bug tracking solutions exist for small teams?
发布评论
评论（14）
对于构建自动化和持续集成，请查看 TeamCity www.jetbrains.com" rel="nofollow noreferrer">Jetbrains。
它有很多功能，并且设置和使用确实非常简单。
如果您使用 Visual Studio 2005/2008，它将直接构建您的解决方案，而不需要额外的脚本（如果构建就是您想要的）。
它还将执行您的单元测试并收集有关构建成功、单元测试执行时间等的统计信息 最重要的是
：专业版对于最多 20 个用户和 3 个构建代理的团队是免费的。
For build automation and continuous integration take a look at TeamCity from Jetbrains.
It has a lot of features and is really a breeze to set up and use.
If you use Visual Studio 2005/2008 it will build your solution directly without the need for extra scripts (if a build is all you want.)
It will also execute your unit tests and gather stats on build success, unit test execution times, etc, etc.
Best of all: The Pro edition is free for teams with up to 20 users and 3 build agents.
查看有关使用 MSBuild、CruiseControl.NET、FxCop、NUnit、NCover 和 Subversion 进行持续集成的文章...
来自软件开发战壕
Check out these articles on Continuous Integration using MSBuild, CruiseControl.NET, FxCop, NUnit, NCover and Subversion...
From the software development trenches
我目前正在使用 SVN，但在签出开发服务器上的网络驱动器时通常会遇到很多问题。 往往存在需要大量摸索才能解决的锁定问题。 使用 WebDav 访问方法可能会缓解其中一些问题，但我还没有尝试过。
Bugzilla、Trac 或 Fogbugz 中的任何一个都可以帮助您进行错误跟踪，并且每个都提供导出功能，因此您以后可以随时改变主意。 此外，如果你能让你的团队完全接受，时间管理软件也可以方便地进行事后分析等（如果每个人都有积极性充分参与的话）。
I'm currently using SVN but I've generally had a lot or problem with checkouts to a network drive on a dev server. There tend to be locking issues that require a lot of fishing around to fix. It may be that using the WebDav access method, would ease some of these problems, but I haven't experimented yet.
Any of Bugzilla, Trac or Fogbugz will help you with your bug tracking, and each offer an export feature, so you can always change your mind later on. Also, if you can get your team to fully buy in, time management software can also be handy for post-mortems, etc (if everyone is motivated to fully participate.
*4) Redmine
我推荐 Bitnami 用于测试不同的堆栈。 它有 Trac、Redmine 和 Subversion，以及其他几个不相关的。
*4) Redmine
I recommend Bitnami for testing out different stacks. It's got Trac, Redmine, and Subversion, as well as several other unrelated ones.
我认为您不再需要在 .Net 上进行混淆（查看另一个回复）
我不会考虑 Vault，SVN 目前确实是市场领导者（而且免费）。 Git 看起来很有前途，但目前只是命令行，学习曲线陡峭。
MSBuild 在 .Net 2 或 3.5 上击败了 NAnt
CC.Net 非常出色。
I don't think you really need obfuscation on .Net any more (see another response)
I wouldn't consider Vault, SVN is really the market leader at the moment (and free). Git is looking pretty promising but currently is command line only with a steep learning curve.
MSBuild beats NAnt for .Net 2 or 3.5
CC.Net is excellent.
一个相对便宜的好问题跟踪器是 axoSoft OnTime。 在获得 MS TFS 之前我使用它多年。
Nant 和 CruiseControl 是我的环境的主要部分。
A good issue tracker that was relatively inexpensive was axoSoft OnTime. I used it for years before getting MS TFS.
Nant and CruiseControl are staples of my environment.
我没有任何工具可以建议，但我确实有关于日常构建的建议。 我对这个问题总是回答“是”，即使我们没有每日构建。 相反，每当有人进行提交时，我们都会进行构建。 因此，我们几乎可以立即发现任何问题。 如果我们的任何项目有足够的 LOC 以至于构建花费了很多时间，那么这样做也会在日常构建的方向上优雅地降级。
I don't have any tools to suggest, but I do have a suggestion about the daily builds. I always answer yes to that question, even though we don't have daily builds. Instead, we do a build every time someone does a commit. We thereby catch any problems almost immediately. If any of our projects ever has enough LOC that building takes more than trivial time, doing this will also gracefully degrade in the direction of a daily build.
我是一个很少音节的人;-)
请务必使用某种版本控制，开发人员可以轻松地创建私有分支，然后将其私有分支压缩到主分支上的单个提交中分支。 这样，个人开发人员（而不是组织）可以获得版本控制的好处，而不会因提交损坏而污染其他人的代码（并减慢他们的工作）。
这个功能正是我喜欢 git 的地方。 我认为它只真正存在于分布式版本控制系统中； 不过，使用 DVCS 并不意味着您实际上必须进行分布式开发。
关于一步构建，make 是默认的构建工具，它对于大多数任务来说效果都很好。 我会同意，除非你有充分的理由不这样做。
您想要每日构建，请将构建命令放入 cron.daily 中。 如果需要，设置 procmail 挂钩来处理来自 cron 的邮件。
对于错误跟踪，请使用
$(apt-cache search bug track)。 基本上，只要盒子上写着“错误跟踪器”并且您知道其他人正在使用它，它可能会正常工作。 常客包括 bugzilla、mantis 和 trac。I'm a man of few syllables ;-)
Be sure to use some kind of version control where developers can easily create private branches willy-nilly, then take their private branch and squeeze it into a single commit on the main branch. That way, individual developers---as opposed to the organization---can get the benefits of version control without polluting anyone else's code (and slowing down their work) with broken commits.
This feature is what I like about git. I think it's only really present in distributed version control systems; using a DVCS doesn't mean you actually have to do distributed development, though.
Regarding one-step building, make is the default build tool and it works quite well for most tasks. I'd go with that unless you have a good reason not to.
You want daily builds, put the build command in your cron.daily. Set up a procmail hook to handle the mail from cron if need be.
For bug tracking, use
$(apt-cache search bug tracking). Basically, as long as it says "bug tracker" on the box and you know other people are using it, it's probably going to work fine. Among the regulars are bugzilla, mantis and trac.1) Subversion
2) Ant / Maven
3) Continuum
4) Bugzilla / Trac
1) Subversion
2) Ant / Maven
3) Continuum
4) Bugzilla / Trac
不要忘记使用 NUnit 进行自动化测试，Fit 和 等待。
Don't forget automated testing with NUnit, Fit, and WatiN.
我的首选堆栈：
1）Subversion。 我对分布式源代码控制很感兴趣，但还没有机会愤怒地尝试。 对于集中式解决方案，svn 是坚如磐石的。
2）蚂蚁。 Maven 在工作时使用起来很愉快，但作为一个老蚂蚁黑客，我发现一旦出现问题，Maven 就很难遵循。
3）哈德森。 到目前为止还没有提到，但绝对值得研究。 令人难以置信的可用和积极维护的工具。 以前我们花钱买了 Anthill Pro，它看起来很不稳定，每次出问题都很难修复。
4）我们支付jira费用。 不便宜，但比我们看到的开源选项更有用，而且也非常灵活。
My preferred stack:
1) Subversion. I'm intrigued about distributed source control but haven't had chance to try any in anger yet. For a centralized solution svn is rock solid.
2) Ant. Maven is a joy to use when it's working but as an old ant hacker I find maven to be hard to follow once things go wrong.
3) Hudson. Not been mentioned so far but definitely worth investigating. Incredibly usable and actively maintained tool. PreviousLy we paid for Anthill Pro which seemed flakey and was painful to fix each time it screwed up.
4) We pay for jira. Not cheap but much more usable than the open source options we looked at and very flexible too.
您可能想查看我的现有问题 寻找团队系统的替代方案。 里面也有很多推荐。
You may want to look at an existing question of mine for finding an alternative to Team System. There are plenty of recommendations in there also.
我的工程堆栈：
毫无疑问，这些选择受到我的开发堆栈的影响，其中最常见的是 Ruby、Rails、SQLite、Firefox 和 OSX 。
My engineering stack:
No doubt these choices are influenced by my development stack, which most often includes Ruby, Rails, SQLite, Firefox, and OSX.