存储库应该包含什么？
我正在尝试建立一个持续集成流程。 对于我的各种构建任务（编译、测试、文档等），我需要拥有执行这些任务的工具（csc、NUnit、NDoc 等）。 我的问题是这些工具也应该进入我的源代码控制存储库吗？
为什么我认为它们应该是因为我在一些在线文章中读到开发人员环境应该与构建服务器环境非常相似。 为了满足这一要求，本文建议您将构建所需的所有内容都放入存储库中，当您签出代码（或构建服务器签出代码）时，您就可以立即构建项目，而无需先安装任何其他工具。 但另一方面，如果我将这些工具与源代码一起放入存储库中，那么每当运行构建时构建服务器都必须安装它们。
安装这些工具可以吗？ 是否会不必要地增加每次构建的时间？
I am trying to set up a Continuous Integration process. For my various build tasks(compiling, testing, documentation etc.)I need to have tools that perform these tasks(csc, NUnit, NDoc etc.). My question is should these tools too go into my source control repository?
Why I think that they should is because I read in some online article that the developer environment should be as much similar to the build server environment. To fulfill this requirement, the article suggested that you put everything that is required for your build in the repository and when you check out the code(or the build server checks out the code) you are ready to build the project right away without first installing any other tools. But on the other hand if I put these tools with my source code in the repository then the build server will have to install them whenever a build is run.
Is it OK to install these tools? Won't it increase the time for each build unnecessarily?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
尝试将工具签入源代码管理通常会带来更多麻烦，而不是值得的。 相反，编写一份在签出和构建源代码之前必须安装的软件要求列表（在任何情况下都需要在此列表中的一件事是源代码控制系统本身）。 如果您依赖于源代码管理中的软件，则可能需要将某些工具安装在某些路径中或进行其他配置（例如注册表项）。
我当然不会将编译器本身检查到源代码控制，而且我可能也不会检查 NUnit 或 NDoc。 只需提前安装它们，因为它们在项目的生命周期中不太可能发生太大变化。 您的构建脚本可能需要检查所需软件包的预期版本是否已安装，然后才能继续构建。
It's often more trouble than it's worth to try to check in tools to source control. Rather, write a list of software requirements that must be installed before the source can be checked out and built (one thing that would need to be on this list in any case is the source control system itself). If you rely on software being in source control, some tools might need to be installed in certain paths or be otherwise configured (registry entries come to mind).
I would certainly not check in the compiler itself to source control, and I probably wouldn't check in NUnit or NDoc either. Just install these beforehand, as they are not likely to change too much over the lifetime of your project. Your build script might want to check that the expected version(s) of the required software packages are installed before the build may proceed.
除非您正在自定义工具，否则可能没有理由将其源代码放入您的存储库中。 然而，将配置文件放入存储库有很好的理由。
Unless you're customizing the tools there's probably no reason to put their source code in your repository. However there are excellent reasons for putting your config files in the repository.
为每个构建重新安装工具太过分了，而且会减慢你的速度。
然而，最好有一个专用于持续集成的服务器，以便您了解其状态； 您确定没有人安装任何可能对构建结果产生影响的东西。
如果您希望明年能够重新生成今天的构建，则需要能够首先重新创建环境。 确保您能够重新安装工具（完全相同的版本），方法是将它们保留在服务器上（在不同的目录中安装较新的版本），或将整个包存储在配置管理工具中。
考虑如何创建另一个持续集成服务器，要么拥有两个服务器，要么用于第二个站点，要么在灾难后恢复。 记录持续集成服务器的设置方式。
真正需要版本控制的是构建脚本，它可以访问正确版本的工具，特别是如果您选择安装多个版本的工具。
Re-installing the tools for every single build is overkill and will slow you down.
However it's by far better to have a server dedicated to the continuous integration so that you know its state ; you sure nobody installed anything that may have an impact on the outcome of the build.
If you want to be able to re-generate today's build next year, you need to be able to re-create your environment first. Make sure you'll be able to re-install your tools (exact same version), either by keeping them on your server (installing the newer versions in different directories), or storing the whole package in your configuration management tool.
Think about how you would create another continuous integration server, either to have two of them, or for a second site, or to recover after a disaster. Document how the continuous integration server was set up.
What really needs to be version controlled, is the build scripts, that access the right versions of the tools, especially if you opt for installing several versions of the tools.