我需要帮助为基于.Net的项目设置开发环境。
我目前正在一个拥有'唯一'开发人员（我）的组织工作。我们在内部开发和维护软件。我们目前正在使用Visual Studio和手动上传文件 - 每次测试/生产（每次都在源代码中进行更改！）。我已经读过“乔尔测试”的优点，并且如果得到适当的话，会给它留下深刻的印象。
我的问题是
1）实现仅涉及单个开发人员的部分或完整功能是否太过分了。
2）对于每个步骤 - 哪些是最好的工具？例如 - 问题1：您使用源代码管理吗？ - 我想知道在我的场景中哪个工具对于实现（1）是好的/最好的。等其他积分也是如此。
其他信息：
我正在寻找当今行业中使用的解决方案。我正在寻找商业和免费解决方案 - 只要它们稳定且具有良好的使用基础。
目前的设置就像这样
IIS-Production，SQL Server-Production
IIS-test，SQL Server-Test
developer machine - with Visual Studio Installed
非常感谢任何帮助 - 我正在寻找一个标准和良好的解决方案，以便将来在那里工作的开发人员变得容易。谢谢！
答案 0 :(得分：1)
显然，对这些问题的任何答案都是主观的，并反映了回答者的经历，偏见等。话虽如此，这是我不那么简短的答案：
1）实施起来并不算太多。也许你不需要得分12，但你绝对应该至少使用源代码控制。
2）最好的工具？这就像问我，“什么是最好的车？”这些东西不仅是主观的，而且最好的工具因情况而异。
（1）无论如何，我喜欢perforce作为源控制系统，我非常喜欢它。我也喜欢mercurial（hg）和git。我还没有真正使用过Team Server，但如果你们都是微软，那么这也许不是一个糟糕的选择。 （我说可能）。
（2）你能一步完成构建吗？您应该能够一步完成构建。 msbuild以及一些python，bat，nant或者其他东西可以让你前进。最好的工具是你最了解的工具。我的选择取决于你想要的强大程度。我喜欢python。
（3）你做日常生成吗？你每天办理登机手续真的会成为问题吗？为什么不建立每次办理登机手续？我们说话的系统有多大，步骤（2）需要多长时间？
（4）你有一个bug数据库吗？我希望你能以记事本之外的其他方式跟踪错误。我喜欢Jira，等等。
（5）你在编写新代码之前修复了错误吗？你应该做这个。我做。
（6）你有最新的时间表吗？这似乎是合乎逻辑的事情。您可以使用Microsoft Schedule，或其他任何100种其他工具。
（7）你有规格吗？如果你正在建造一些比工作更长的东西，那么写下你正在建造的东西可能是值得的。这些事情很明显，不是吗？试试Visio。
（8）程序员的工作环境是否安静？我喜欢工作时的音乐，但如果需要安静，它应该可用。
（9）你使用钱可以买的最好的工具吗？我发现许多最好的工具都是免费的，但是ymmv，显然手头的工作决定了最好的工具。
（10）你有测试人员吗？如果你现在不这样做，我希望你能。
（11）新候选人在面试时是否编写代码？这似乎是一种很好的做法。
（12）你做走廊可用性测试吗？我想这个取决于你正在制作的产品，但它可能不会受到伤害。
这些乔尔测试中只有少数确实需要工具，希望我能给你一些偏见和主观的答案。
答案 1 :(得分：1)
嗯，Joel Test绝对适合比你更大的软件开发组织。
因此，在尝试实现12之前不要忘记使用常识（这个建议代表任何组织规模，但是:-)）。
对于唯一的开发者，我会推荐以下内容。
源控制系统是必须的。否则你会很快陷入困境，比如'我猜，这个错误是在两周前我在那里添加了一个函数时引入的......'。 Subversion是一个很好的选择。 Git和Perforce也是不错的选择（后者需要花钱，尽管他们为2个用户提供免费许可）。我不会在这里推荐Microsoft工具。
任务（错误/功能）数据库也是必须的，因为您想知道自己的目的地并跟踪进度。如果只涉及一两个人，则不需要完整的问题跟踪系统。有一个是很好的，但是对于大多数实际用途，Excel spredsheet都没问题 您可以尝试Jira（afair，他们为拥有＆lt; 10开发人员的组织提供免费许可证）或Trac。
在编码之前编写规范。这可能并不明显，但规格很有用。它使您在实际实施之前就可以仔细考虑未来实施的许多细节，从而避免花费大量时间朝错误的方向前进。此外，一个好的规范将对您的客户，项目的继任者等有所帮助。
一致的部署程序。不要将开发配置中的代码上传到生产环境。很容易忘记你刚才做的一些重要的改变，或者你添加了一些调试代码，或者一些未提交的文件等等。制定一个规则，即每次更改都先进行源控制，然后从源控制器重建并进行测试，之后将其部署到生产中。
如果您的项目很小，使用构建服务器可能会过度，因此可以使用简单的批处理文件，Powershell脚本或Nant脚本。在任何一种情况下，请确保构建过程与开发配置和自动构建之间存在尽可能的差异（以避免“它适用于我的机器”综合症）。
要尝试的好构建服务器是CruiseControl.Net（FOSS）和TeamCity（小型项目免费）。
自动化测试。如果操作得当，手动测试的工时费用很昂贵。由开发人员和/或客户执行的手动测试通常不能正确完成，因此不是非常有用。自动化测试也不容易，但从长远来看，它可以帮助您避免很多麻烦。单元测试是小型项目所需的最低限度，系统测试更难以进行，因此在部署之前和之后可能会进行一些自动（甚至是手动）完整性检查。 MSTest或NUnit是良好的单元测试框架。
每日构建本身不会给你太多。它是一个很好的工具，可以捕获不同人员在项目的不同部分中引入的不一致性，但对于一个小型的单一开发人员项目，它不会给你太多。
金钱可以购买的最好的工具是昂贵的（假设你不会使用盗版软件）对于一家小公司来说可能是负担不起的。很多时候你可以免费得到几乎相同的东西
如果您在不同的Visual Studio版本之间进行选择，请注意单元测试功能 - MSTest本身和代码覆盖支持。其他差异，实际上是微不足道的（尽管你可以使用免费的NUnit和NCover）。
如果你能负担得起，Resharper是一项非常有价值的投资，imho。