我正在尝试设置一个持续集成过程。对于我的各种构建任务（编译，测试，文档等），我需要具有执行这些任务的工具（csc，NUnit，NDoc等）。我的问题是这些工具是否也会进入我的源代码控制库？存储库应包含哪些内容？
为什么我认为他们应该是因为我在一些在线文章中读到开发人员环境应该与构建服务器环境非常相似。为了满足这个要求，文章建议你将所有必要的东西放到版本库中，当你签出代码（或者构建服务器签出代码）时，你可以立即开始构建项目，而无需首先安装任何其他工具。但另一方面，如果我将这些工具与我的源代码放在版本库中，那么构建服务器将在构建版本运行时安装它们。
可以安装这些工具吗？不会不必要地增加每个版本的时间？
通常比试图检查工具来源控制的工作更麻烦。相反，编写一个必须安装的软件需求清单，然后才能检出和构建源文件（在任何情况下，需要在此清单上列出的一件事是源控制系统本身）。如果您依赖于源代码管理中的软件，则某些工具可能需要安装在某些路径中或以其他方式配置（注意到注册表项）。
我当然会不是检查编译器本身的源代码控制，我可能不会检查NUnit或NDoc。只需事先安装这些软件，因为它们在项目的整个生命周期中不可能发生太大的变化。您的构建脚本可能希望在构建可能继续之前检查是否安装了所需软件包的预期版本。
除非您正在自定义这些工具，否则可能没有理由将其源代码放入您的存储库。但是，将配置文件放入存储库有极好的理由。
为每一个版本重新安装工具是矫枉过正的，会让你放慢速度。
然而，有一个服务器致力于持续集成，以便知道它的状态;你确定没有人安装任何可能对构建结果产生影响的东西。
如果您希望能够在明年重新生成今天的版本，那么您需要先重新创建环境。确保您可以重新安装您的工具（完全相同的版本），可以将它们保留在服务器上（将新版本安装在不同目录中），也可以将整个软件包存储在配置管理工具中。
想想你将如何创建另一个持续集成服务器，既可以拥有其中两个服务器，也可以创建另一个站点，或者在灾难发生后恢复。 文件如何建立持续集成服务器。
什么真的需要版本控制，是构建脚本，访问正确版本的工具，特别是如果你选择安装几个版本的工具。