我没有为非常大的组织工作过，也从未为拥有“构建服务器”的公司工作过。
他们的目的是什么？
为什么开发人员不在他们的本地机器上构建项目，或者他们是？
某些项目是否如此庞大以至于需要更强大的机器才能在合理的时间内构建它？
我认为构建服务器有用的唯一地方是与构建服务器持续集成，不断构建提交到存储库的内容。是不是我没有参与过足够大的项目？
有人请赐教：构建服务器的目的是什么？
问问题
58351 次
18 回答
97
给出的理由实际上是一个巨大的好处。去 QA 的构建应该只来自一个只从存储库构建的系统。这种方式构建包是可重现和可追溯的。开发人员手动为除了他们自己的测试之外的任何东西构建代码是危险的。东西没有被签入的风险太大，与其他人的更改过时等等等等。
于 2009-07-08T16:27:08.687 回答
50
构建服务器之所以重要有几个原因。
他们隔离环境 当本地Code Monkey 开发人员无法在您的机器上编译时，它会说“它在我的机器上编译”。这可能意味着签入不同步，或者可能意味着缺少依赖库。jar 地狱没有 .dll 地狱那么糟糕；无论哪种方式，使用构建服务器都是廉价的保险，您的构建不会神秘地失败或错误地打包错误的库。
他们专注于与构建相关的任务。这包括更新构建标签、创建任何分发包、运行自动化测试、创建和分发构建报告。自动化是关键。
他们协调（分布式）开发。标准情况是多个开发人员在同一代码库上工作。版本控制系统是这种分布式开发的核心，但根据工具的不同，开发人员可能不会与彼此的代码进行太多交互。与其强迫开发人员冒错误构建的风险或担心过于激进地合并代码，不如设计构建过程，使自动构建可以看到适当的代码并以可预测的方式处理构建工件。这样，当开发人员提交有问题的事情时，比如没有签入新的文件依赖项，他们可以很快得到通知。在分段区域中执行此操作让您标记已构建的代码，以便开发人员不会提取会破坏其本地构建的代码。PVCS 使用促销组的想法做得很好。Clearcase 也可以使用标签来做到这一点，但需要比许多商店提供的更多的流程管理。
于 2009-07-08T16:56:59.407 回答
29
他们的目的是什么？
承担开发人员机器的负载，为构建提供稳定、可重现的环境。
为什么开发人员不在他们的本地机器上构建项目，或者他们是？
因为对于复杂的软件，令人惊讶的是，仅仅“编译通过”就会出现许多错误。我实际遇到的问题：
- 不同种类的不完整的依赖检查，导致二进制文件没有被更新。
- 发布命令静默失败，日志中的错误消息被忽略。
- 构建包括尚未提交源代码控制的本地资源（幸运的是，还没有“该死的客户”消息框......）。
- 当试图通过从另一个文件夹构建来避免上述问题时，一些文件是从错误的文件夹中挑选出来的。
- 聚合二进制文件的目标文件夹包含不应包含在发行版中的其他陈旧开发人员文件
由于所有公共版本都从源代码控制获取到一个空文件夹开始，因此我们获得了惊人的稳定性提升。以前，有很多“有趣的问题”“当乔给我一个新的 DLL 时就消失了”。
某些项目是否如此庞大以至于需要更强大的机器才能在合理的时间内构建它？
什么是“合理”？如果我在本地机器上运行批处理构建，有很多事情我不能做。与其向开发人员付费以完成构建，不如向 IT 付费以购买真正的构建机器。
是不是我没有参与过足够大的项目？
大小当然是一个因素，但不是唯一的因素。
于 2009-07-08T16:47:08.053 回答
8
构建服务器是一个与持续集成服务器不同的概念。CI 服务器的存在是为了在进行更改时构建您的项目。相比之下，构建服务器的存在是为了在干净的环境中构建项目（通常是发布，针对标记的修订版）。它确保没有开发人员破解、调整、未经批准的配置/工件版本或未提交的代码进入发布的代码。
于 2009-07-08T16:31:38.523 回答
6
构建服务器用于在签入时构建每个人的代码。您的代码可能会在本地编译，但您很可能不会一直拥有其他人所做的所有更改。
于 2009-07-08T16:26:23.337 回答
5
补充已经说过的内容：
一位在 Microsoft Office 团队工作的前同事告诉我，一个完整的构建有时需要 9 个小时。在你的机器上做这件事会很糟糕，不是吗？
于 2010-11-24T17:57:36.947 回答
4
有必要拥有一个没有以前版本（和配置更改）的工件的“干净”环境，以确保构建和测试工作并且不依赖于工件。一种有效的隔离方法是创建一个单独的构建服务器。
于 2009-07-08T16:30:12.737 回答
4
我同意迄今为止关于稳定性、可追溯性和可再现性的答案。（很多'ity'，对吧？）。我只为拥有许多构建服务器的大公司（医疗保健、金融）工作过，我想补充一点，这也是关于安全性的。看过电影办公空间吗？如果一个心怀不满的开发人员在他的本地机器上构建了一个银行应用程序，而没有其他人查看或测试它...... BOOM。超人三世。
于 2009-07-08T16:35:33.133 回答
3
使用这些机器有几个原因，所有这些都试图帮助您提供优质的产品。
一种用途是模拟典型的最终用户配置。该产品可能在您的计算机上运行，并设置了您的所有开发工具和库，但最终用户很可能不会拥有与您相同的配置。就此而言，其他开发人员也不会拥有与您完全相同的设置。如果您的代码中某处有硬编码路径，它可能会在您的机器上运行，但是当 Dev El O'per 尝试构建相同的代码时，它将无法运行。
它们还可以用来监控谁最后破坏了产品，更新了什么，以及产品在哪里退化。每当签入新代码时，构建服务器都会构建它，如果它失败，则很明显有问题并且最后提交的用户有错。
于 2009-07-08T16:31:55.977 回答
2
为了获得一致的质量并让构建“脱离您的机器”以发现环境错误，以便您忘记签入源代码控制的任何文件也显示为构建错误。
我还使用它来创建安装程序，因为这些需要花费大量时间在桌面上进行代码签名等操作。
于 2009-07-08T16:26:57.597 回答
1
我们使用一个，以便我们知道生产/测试框安装的库和这些库的版本与构建服务器上可用的库相同。
于 2009-07-08T16:26:06.833 回答
1
这是关于我们的管理和测试。使用构建服务器，我们总是知道我们可以从版本控制构建我们的主要“主干”线。我们可以一键创建主安装并将其发布到网络上。每次签入代码时，我们都可以运行所有单元测试以确保其正常工作。通过将所有这些任务收集到一台机器中，可以更轻松地重复完成任务。
于 2009-07-08T16:28:09.807 回答
1
你是对的，开发人员可以在他们自己的机器上构建。
但这些是我们的构建服务器给我们买的一些东西，我们几乎不是成熟的构建制造商：
- 版本控制问题（之前的回复中已经提到了一些）
- 效率。开发人员不必停下来在本地进行构建。他们可以在服务器上启动它并继续下一个任务。如果构建很大，那么开发人员的机器不被占用的时间就更多了。对于那些进行持续集成和自动化测试的人来说，甚至更好。
- 集权。我们的构建机器具有构建脚本，将其分发到 UAT 环境，甚至是生产阶段。将它们放在一个地方可以减少保持它们同步的麻烦。
- 安全。我们在这里没有做太多特别的事情，但我确信系统管理员可以做到这一点，使得生产迁移工具只能由某些授权实体在构建服务器上访问。
于 2009-07-08T16:40:28.583 回答
1
也许只有我一个...
我想每个人都同意应该
- 使用文件存储库
- 从存储库构建（并且在干净的环境中）
- 使用持续测试服务器（例如巡航控制）查看“修复”后是否有任何问题
但是没有人关心自动构建的版本。当自动构建中的某些东西被破坏时，但它不再是 - 谁在乎？这是一项正在进行的工作。有人修好了。
当您想要发布版本时，您可以从存储库运行构建。而且我很确定您当时想在存储库中标记版本，而不是在服务器工作时每六个小时标记一次。
因此，也许“构建服务器”只是用词不当，它实际上是“持续测试服务器”。否则听起来几乎没用。
于 2009-07-08T16:46:28.430 回答
0
构建服务器可以让您对您的代码有另一种看法。当您签入时，将检查代码。如果它有效，则代码具有最低质量。
于 2009-07-08T16:29:51.957 回答
0
此外，请记住，低级语言的编译时间比高级语言要长得多。很容易想到“好吧，看，我的 .Net 项目在几秒钟内就编译好了！有什么大不了的？” 不久前，我不得不处理一些 C 代码，我忘记了编译需要多长时间。
于 2009-07-08T16:38:49.210 回答
0
构建服务器用于安排通常位于存储库中的大型项目的编译任务（例如，夜间构建），有时可能需要几个小时以上。
于 2009-07-09T06:57:26.007 回答
0
构建服务器还为您提供了托管的基础，能够在其他人可能有权获得所有权的情况下捕获复制构建所需的所有部分。
于 2009-08-24T00:21:23.370 回答