“构build服务器”有什么意义？
我没有为非常大的组织工作过，也从来没有为拥有“构build服务器”的公司工作过。
他们的目的是什么？ 为什么不是开发人员在本地机器上构build项目，还是他们？ 有些项目是如此之大，需要更强大的机器来在合理的时间内构build它？
我看到构build服务器的唯一有用的地方是与构build服务器的持续集成，不断构build致力于存储库的内容。 难道我只是没有足够的项目工作？
有人请赐教：构build服务器的目的是什么？
给出的理由实际上是一个巨大的好处。 构buildQA的构build应该只来自仅从存储库构build的系统。 这样构build软件包是可重复和可追踪的。 除了自己的testing，开发人员手动构build代码是非常危险的。 太多的东西没有得到检查，与其他人的变化等过时的风险等。
乔尔·斯波尔斯基就此事。
构build服务器有几个重要的原因。
-
他们孤立的环境当地的Code Monkey开发者说：“它编译在我的机器上”，当它不会在你的编译。 这可能意味着不同步的签入，也可能意味着依赖的库缺失。 Jar地狱并不像地狱一样糟糕， 无论如何，使用构build服务器是廉价的保险，你的构build不会神秘地失败或错误地包装错误的库。
-
他们专注于与构build相关的任务。 这包括更新构build标记，创build任何分发包，运行自动化testing，创build和分发构build报告。 自动化是关键。
-
他们协调（分布式）发展。 标准的情况是多个开发人员在相同的代码基础上工作。 版本控制系统是这种分布式开发的核心，但是取决于工具，开发人员可能不会彼此交互。 不要强迫开发人员冒险构build糟糕的构build，或担心过度积极地合并代码，devise构build过程中自动构build可以看到适当的代码并以可预测的方式处理构build工件。 这样，当开发人员提出某个问题时，比如不检查新的文件依赖性，他们可以很快得到通知。 在一个staged区域做这个事情，让我们标记已经构build的代码，以便开发人员不会提取会破坏本地构build的代码。 PVCS使用推广小组的想法做得很好。 Clearcase也可以使用标签来实现，但需要更多的stream程pipe理，而不是许多商店提供的。
他们的目的是什么？
加载开发者机器，为构build提供稳定，可重复的环境。
为什么不是开发人员在本地机器上构build项目，还是他们？
因为使用复杂的软件，很多事情在“编译通过”时会出错。 我实际遇到的问题：
- 不同types的不完全依赖性检查，导致二进制文件不被更新。
- 发布失败的静默命令，日志中的错误消息被忽略。
- build设包括本地来源还没有承诺源控制（幸运的是，没有“该死的客户”消息框呢..）。
- 当试图通过从另一个文件夹构build来避免上述问题时，某些文件从错误的文件夹中选取。
- 二进制文件聚集的目标文件夹包含额外的陈旧的开发人员文件，不包含在版本中
由于所有公开发布都是从源代码控制获取到一个空文件夹，所以我们得到了惊人的稳定性提升。 之前，有很多“有趣的问题”，“当乔给我一个新的DLL”走了。
有些项目是如此之大，需要更强大的机器来在合理的时间内构build它？
什么是“合理的”？ 如果我在本地机器上运行批处理构build，则有许多事情我不能做。 支付IT购买真正的生成机器，而不是付费开发商完成。
难道我只是没有足够的项目工作？
规模肯定是一个因素，但不是唯一的一个。
构build服务器是连续集成服务器的一个独特概念。 CI服务器的存在是为了在更改时build立你的项目。 相比之下，Build服务器就存在于一个干净的环境中构build项目（通常是一个版本，针对已标记的版本）。 它可以确保没有开发人员入侵，调整，未经批准的configuration/构件版本或未提交的代码使其进入已发布的代码。
构build服务器用于在签入时build立所有人的代码。您的代码可以在本地进行编译，但是您很可能不会一直进行所有其他人所做的更改。
我同意迄今为止关于稳定性，可追踪性和再现性的答案。 （很多'的，是吧？）。 我曾经为大型公司（医疗保健，金融）工作过，拥有很多服务器，所以我想补充一点，这也是关于安全的。 曾经看过电影“办公空间”？ 如果一个心怀不满的开发者在他的本地机器上build立一个银行应用程序，而没有其他人看着它或者testing它…… BOOM。 超人三。
为了确保构build和testing的正常工作并且不依赖于构件，有必要有一个没有以前版本（和configuration更改）的工件的“干净”环境。 一个有效的隔离方法是创build一个独立的构build服务器。
这些机器的使用有几个原因，都试图帮助您提供优质的产品。
一个用途是模拟典型的最终用户configuration。 该产品可能在您的计算机上运行，所有的开发工具和库都已设置，但最终用户很可能不会与您具有相同的configuration。 对于这个问题，其他的开发者也不会有和你一样的设置。 如果你的代码中有一个硬编码的path，它可能会在你的机器上工作，但是当Dev El O'per试图构build相同的代码时，它将不起作用。
他们也可以用来监视谁最后打破了产品，什么更新，产品倒退在哪里。 无论何时检入新代码，构build服务器都会构build它，如果失败，则清除错误，最后提交的用户出错。
补充一下已经说过的话：
一位前同事在微软Office团队工作，并告诉我一个完整的构build有时需要9个小时。 这会吸引你的机器，不是吗？
为了保持一致的质量，并使构build“closures你的机器”来发现环境错误，并且任何忘记login到源代码控制的文件都会显示为构build错误。
我也使用它来创build安装程序，因为这些需要花费很多时间在桌面上执行代码签名等。
我们使用一个，以便我们知道生产/testing框具有与生成服务器上可用的库相同的库和版本。
这是关于我们的pipe理和testing。 使用构build服务器，我们总是知道我们可以从版本控制构build我们的主“主干”行。 我们可以通过一键创build一个主安装并将其发布到networking上。 每次检入代码时，我们都可以运行所有的unit testing，以确保它能正常工作。 通过将所有这些任务收集到一台机器中，可以更容易地重复使用。
你是对的，开发人员可以在自己的机器上构build。
但是，这些是我们的构build服务器购买我们的一些东西，我们也不是很复杂的构build者：
- 版本控制问题（以前的回复中提到过一些问题）
- 效率。 开发人员不必停下来在本地进行构build。 他们可以在服务器上启动它并继续下一个任务。 如果构build量很大，那么开发者的机器没有被占用的时间更多。 对于那些进行持续集成和自动化testing的人来说，更好。
- 集权。 我们的构build机器具有构build的脚本，将其分发到UAT环境，甚至分发到生产舞台。 保持在一个地方减less了保持同步的麻烦。
- 安全。 我们在这里没有太多特别的地方，但是我确信一个系统pipe理员可以使得生产迁移工具只能被某些授权实体在构build服务器上访问。
也许我是唯一一个…
我认为每个人都应该同意
- 使用文件存储库
- 从版本库（并在干净的环境中）
- 使用连续testing服务器（例如巡航控制）来查看在“修复”后是否有任何内容被损坏
但是没有人关心自动构build的版本。 当一个自动构build中的东西被打破了，但现在不在了 – 谁在乎？ 这是一个正在进行的工作。 有人修复它。
当你想做一个发行版时，你从版本库运行一个版本。 而且我非常肯定你当时想在版本库中标记版本，而不是在服务器运行的时候每六个小时都要标记一次版本。
所以，也许一个“构build服务器”只是一个误导，它实际上是一个“连续testing服务器”。 否则，这听起来几乎没用。
构build服务器让你对代码有一种第二意见。 当你签入时，代码被检查。 如果有效，代码的质量最低。
另外，请记住，低级语言比高级语言编译需要更长的时间。 很容易想到：“看，我的.Net项目在几秒钟内编译完成，有什么大不了的？” 一会儿，我不得不瞎搞一些C代码，忘记了编译需要多长时间。
构build服务器用于安排位于存储库中的通常大型项目的编译任务（例如每晚构build），有时可能需要几个小时。
构build服务器还为您提供托pipe基础，在其他人有权获取所有权的情况下，能够捕获重build构build所需的所有部分。
