“构建服务器”的意义是什么？[关闭]

我没有在大型组织工作过，也从未在拥有“构建服务器”的公司工作过。

他们的目的是什么？开发人员为什么不在本地计算机上构建项目呢？是否有一些项目如此之大，以至于需要更强大的机器来在合理的时间内构建它？

我看到构建服务器有用的唯一地方是与构建服务器的持续集成，不断构建提交给存储库的内容。我只是还没有从事足够大的项目吗？

有人，请启发我：构建服务器的目的是什么？

给出的原因实际上是巨大的好处。进行质量检查的构建只能来自仅从存储库构建的系统。这样，构建包是可复制和可追溯的。开发人员为自己的测试以外的任何内容手动构建代码很危险。东西没有被检入，与他人的更改过时等的太多风险。

乔尔·斯波斯基（Joel Spolsky）在这件事上。

构建服务器之所以重要，有几个原因。

• 他们隔离环境当地的Code Monkey开发人员说“它在我的计算机上编译”，而不会在您的计算机上编译。这可能意味着不同步签入，或者可能意味着缺少依赖库。Jar地狱不如.dll地狱那么糟糕；无论哪种方式，使用构建服务器都是便宜的保险，因为您的构建不会神秘地失败或错误地打包错误的库。

• 他们专注于与构建相关的任务。这包括更新构建标记，创建任何分发包，运行自动化测试，创建和分发构建报告。自动化是关键。

• 他们协调（分布式）开发。标准情况是多个开发人员在同一个代码库上工作。版本控制系统是这种分布式开发的核心，但是根据工具的不同，开发人员之间的交互可能不会太多。与其强迫开发人员冒着糟糕的构建风险或担心过度激进地合并代码，不如设计构建过程，使自动构建可以看到适当的代码并以可预测的方式处理构建工件。这样，当开发人员提交有问题的内容（例如不签入新文件依赖项）时，可以迅速收到通知。在暂存区域中执行此操作，让您标记已构建的代码，以使开发人员不会提取会破坏其本地构建的代码。PVCS使用晋升小组的想法做得很好。Clearcase也可以使用标签来做到这一点，但是与许多商店所关心的相比，Clearcase需要更多的过程管理。

他们的目的是什么？
承担开发人员机器的负担，为构建提供稳定，可复制的环境。

开发人员为什么不在本地计算机上构建项目呢？
因为使用复杂的软件，令人惊讶的是，仅当“编译通过”时，许多事情都会出错。我实际遇到的问题：

• 不同种类的依赖项检查不完整，导致二进制文件无法更新。
• 发布命令以静默方式失败，日志中的错误消息被忽略。
• 包含尚未提交到源代码管理的本地源代码的构建（幸运的是，还没有“该死的客户”消息框。）。
• 当试图通过从另一个文件夹进行构建来避免上述问题时，某些文件是从错误的文件夹中选取的。
• 聚集二进制文件的目标文件夹包含其他过时的开发人员文件，这些文件不应包含在发行版中

由于所有公共发行版都从从源代码管理到空文件夹的获取开始，所以我们的稳定性有了惊人的提高。以前，有很多“有趣的问题”，“当乔给我一个新的DLL时就消失了”。

是否有一些项目如此之大，以至于需要更强大的机器来在合理的时间内构建它？

什么是“合理”？如果我在本地计算机上运行批处理构建，则很多事情我做不到。与其付钱给开发人员完成构建，不如付钱给IT购买真正的构建机器。

我只是还没有从事足够大的项目吗？

大小当然是一个因素，但不是唯一的因素。

对于持续集成服务器，构建服务器是一个独特的概念。进行更改时，存在CI服务器用于构建项目。相比之下，存在一个构建服务器，用于在干净的环境中构建项目（通常是针对标记版本的发行版）。它确保没有开发人员的hack，调整，未经批准的配置/工件版本或未经授权的代码将其纳入发布的代码中。

生成服务器用于签入每个人的代码。您的代码可以在本地编译，但是您很可能不会一直由其他人进行所有更改。

要补充已经说过的话：

一位前同事在Microsoft Office团队工作，并告诉我完整的构建有时需要9个小时。在您的机器上完成该操作很麻烦，不是吗？

必须有一个“干净”的环境，其中没有以前版本的构件（和配置更改），以确保构建和测试有效且不依赖构件。隔离的有效方法是创建单独的构建服务器。

我同意到目前为止有关稳定性，可跟踪性和可复制性的答案。（很多“实体”，对吧？）。仅使用大型构建服务器为大型公司（卫生保健，金融）工作过，我还要补充一点，这也与安全性有关。看过电影《办公空间》吗？如果心怀不满的开发人员在其本地计算机上构建银行业务应用程序，而没有人看着它或对其进行测试……BOOM。超人III。

这些机器的使用有多种原因，所有这些都试图帮助您提供优质的产品。

一种用途是模拟典型的最终用户配置。该产品可能会在您的计算机上运行，​​并设置了所有开发工具和库，但是最终用户很可能不会拥有与您相同的配置。因此，其他开发人员将不会拥有与您完全相同的设置。如果您的代码中有某个硬编码的路径，则该路径可能会在您的计算机上工作，但是当Dev El O'per尝试构建相同的代码时，它将无法工作。

它们还可以用来监视谁最后破坏了产品，更新了什么以及产品退回了哪里。每当签入新代码时，构建服务器都会对其进行构建，如果失败，则表明存在问题，并且最后提交的用户有错。

为了获得一致的质量，并使构建“脱离您的机器”以发现环境错误，使您忘记签入源代码管理的所有文件也显示为构建错误。

我还使用它来创建安装程序，因为这些安装程序需要大量时间在桌面上执行代码签名等操作。

我们使用一个，以便我们知道生产/测试盒具有与构建服务器上可用的库和版本相同的库。

这是关于我们的管理和测试。使用构建服务器，我们始终知道我们可以从版本控制中构建主“ trunk”行。我们可以一键创建主安装并将其发布到Web。每次检入代码以确保其正常工作，我们都可以运行所有单元测试。通过将所有这些任务收集到一台计算机中，可以更轻松地重复进行正确处理。

开发人员可以在自己的计算机上构建是正确的。

但是这些是我们的构建服务器购买给我们的东西，我们几乎不是老练的构建制造商：

• 版本控制问题（在先前的答复中已经提到了一些问题）
• 效率。开发人员不必停止在本地进行构建。他们可以在服务器上启动它，然后继续执行下一个任务。如果构建量很大，那么开发人员的机器将不被占用更多时间。对于那些进行持续集成和自动化测试的人来说，甚至更好。
• 集权。我们的构建机器具有脚本来进行构建，将其分发到UAT环境，甚至分发到生产阶段。将它们放在一个位置可以减少使它们保持同步的麻烦。
• 安全。我们在这里没有做太多特别的事情，但是我确信系统管理员可以做到这一点，使得生产迁移工具只能由某些授权实体在构建服务器上访问。

也许我是唯一的一个...

我认为每个人都同意

• 使用文件存储库
• 从存储库（在干净的环境中）进行构建
• 使用连续测试服务器（例如巡航控制系统）查看“修复”后是否有任何损坏

但是没有人关心自动构建的版本。当某个东西在自动构建中被破坏了，但是现在不再了，谁在乎呢？这项工作正在进行中。有人修好了。

当您想要发布版本时，可以从存储库中运行构建。我敢肯定要标记在资源库中的版本是当服务器做它的工作时间，而不是每六小时。

因此，也许“构建服务器”只是用词不当，实际上是“连续测试服务器”。否则，这听起来毫无用处。

构建服务器使您对代码有第二种看法。签入时，将检查代码。如果可行，则代码质量最低。

另外，请记住，与高级语言相比，低级语言的编译时间要长得多。很容易想到“好吧，我的.Net项目在几秒钟内即可编译！有什么大不了的？” 前一段时间，我不得不弄乱一些C代码，而我忘记了编译需要花费多长时间。

构建服务器用于安排通常位于仓库中的大型项目的编译任务（例如，每晚构建），有时可能要花费几个小时以上。

构建服务器还为您提供了托管的基础，在其他人可能拥有所有权的情况下，它能够捕获复制构建所必需的所有部分。