专用构建机器的目的是什么？

由于多种原因导致上一个构建周期的部署不佳，我竞选办公室使用专用的构建机器执行所有将来的部署，而我的老板接受了这个建议。

但是，我们不必在办公室使用一台实际的机器，而必须与其他几个小组共享一台机器-麻烦的是必须带着所有必要的信息离开我的办公室然后走上楼梯到另一个办公室来执行简单的构建，这让我想知道为什么我一开始就提出这个建议。

最初，拥有一台单独的构建机器的想法是，将我自己的本地编写的代码与其他几名开发人员的代码分开，并从部署中分离出我在机器上拥有的所有劫持文件。这也是为了解决我对ClearCase文件管理系统日益增长的担忧，该系统通常拒绝让我部署某些构建活动，除非我还包括了另一个具有“依赖关系”的活动。

现在，我实际上正在执行此过程，我想知道我是否误解了使用构建机器的全部目的-并且由于我们仅使用该机器将代码部署到我们的测试，登台和生产环境，以及不是针对我们的个人开发人员测试部署，我不确定它是否有任何用途。

那么，使用构建机器的真正原因是什么，我什至接近正确使用它？

通常，您不仅会拥有专用的构建机器，而且还会在该专用机器上运行构建服务器。专用的构建机器仅提供的优点是，不会阻塞开发人员的工作，也不会从集中式机器进行部署。

构建服务器提供了更多功能。构建服务器允许CI（连续集成），这意味着它将在每次推送到VC​​S时自动构建（例如git），如果有的话甚至可以执行单元测试并允许“一键部署”。如果构建或测试失败，构建服务器可以通过邮件通知您。他们提供了发生的历史数据和趋势。

通常，可以使用在浏览器中运行的Web gui，一次由多个用户或团队访问构建服务器。

在Java世界中，最常用的构建服务器之一是Jenkins。Jenkins也可以很好地与C ++构建一起工作（因为您似乎使用了这两种语言）。Jenkins称其为自动化服务器，因为它可以运行与编程和构建无关的所有任务。

除了Traubenfuchs的回答外，您还暗示了问题中使用构建机器的另一个原因。

仅仅因为该软件可以在您的计算机上构建，并不意味着它可以在其他任何人的计算机上构建。您可能依赖于恰好在计算机上的一些随机文件（甚至可能不受版本控制）。您可能依赖于从晦涩的构建脚本中调用的一些被遗忘的应用程序或库。

如果您拥有专用的构建机器，则应该知道安装了什么机器。这应该有据可查。如果需要重建软件，也许是在数年之后，则只需要创建一个新的构建机器，并在上面安装文档化的内容即可。

拥有专用构建机器的主要原因是获得一致的构建，而不管谁在进行构建。开发人员工作站很少（读：从不）相同。很难知道每个版本都使用相同版本的依赖项和编译器等。开发工作站版本最严重的问题之一是，开发人员可以从未经检查的代码进行版本控制。

目前尚不清楚您使用的是哪种平台/语言，但理想情况下，您应该拥有一个直接从源代码控制中提取的构建服务器。也就是说，当需要构建时，它将从给定版本的存储库中检索源，并自动对其进行编译。这需要使用自动构建工具来编写构建脚本。如果没有这个，那应该是第一步。

请记住，在本地进行开发没有任何问题。您绝对应该在本地运行单元测试，代码质量分析和珩磨构建脚本。否则，您将浪费大量时间。构建服务器的输出用于您可能要转移到生产中的所有内容。诸如集成和验收测试之类的所有QA活动仅应使用构建服务器中的构建来完成。

其他答案很正确地指出，您应该自动化构建，这意味着不必走到另一个办公室。但是，让我提出一些步骤，您可以采取一些步骤来改进您的构建过程：

• 首先，设置对构建服务器的远程访问！如果您通过键入命令“ make”进行手动构建，则意味着您不必再步行到另一个办公室来键入“ make”，您只需通过SSH进入构建服务器并键入“ make”即可。如果您尚未使用make或类似的构建系统，请使用这种构建系统。
• 其次，安装一个持续集成环境，该环境会自动从版本控制系统（您有一个版本控制系统，对吗？如果没有，那将是一个额外的步骤）中获取最新更改，并进行构建。我推荐詹金斯。设置Jenkins也可以运行您的单元测试和系统级集成测试（您确实拥有这两种方法，对吗？如果没有，则从单元测试开始创建它们，然后结束于系统级集成测试）。
• 第三，如果发现与其他团队共享同一台机器有问题（例如，对于应该使用的操作系统，版本和功能有不同的看法），请考虑使用虚拟化。如今，一台好的服务器可以运行大量的虚拟机。也许您可以将自己设置为32位计算机和64位计算机，以使您知道构建可在两种体系结构上使用。
• 最后，这可能不是必需的：如果您绝对必须拥有一台专用计算机，例如您的应用程序性能非常重要，并且同时运行的其他构建/测试运行对您的结果影响太大，请安装专用的硬件服务器，而不是只有你用。但是，在可能具有多达40个甚至更多的虚拟CPU内核的最新服务器上，创建一些不共享对同一CPU内核的访问权的虚拟机是相对简单的。

我认为共享计算机比手动构建好得多。我当前的项目现在使用虚拟机，但是由于需要进行系统级集成性能测试，因此我们正在迁移到具有40个虚拟CPU内核的专用服务器，其中性能测试需要17个。

...我们不必在办公室使用一台实际的机器，而是必须与其他几个小组共享一台机器...

你说那是一件坏事。

现在，您将拥有一个通用的构建服务器，可以构建您所有构建（包括您和其他团队）的构建。构建的一致性？校验。

……必须带着所有必要的信息离开我的办公室，然后沿着楼梯走到另一个办公室以进行简单的构建的麻烦，让我感到奇怪，为什么我首先提出了这个建议。

您仍在手动执行构建，这不好。

您需要一个服务器进程，您可以向该服务器进程提交/排队构建请求，并让该进程将结果发送回给您。

除了其他相关答案之外，这听起来还像您是直接在有问题的机器上运行构建。

对于可靠的构建系统，尤其是与其他用户共享构建计算机时，通常在虚拟机中运行构建。这样可以确保其他用户无法通过安装自己的代码依赖的应用程序或库版本来更改构建行为。这样做的一个很大的优点是可以轻松备份VM，也可以轻松将其克隆到任何其他PC（包括您自己的开发计算机）上。

它提供了一个集中的，中立的位置来执行构建，而独立于单个开发人员的IDE，OS和库配置。

使用专用的构建机器，您可以在每次将代码推送到存储库时对其进行重建。当有人中断构建时，该过程可以立即发出警报，以便可以立即解决问题。

除了使所有内容更具可重复性和可靠性，并确保存储库中不存在因依赖问题而潜伏的残破垃圾之外，它还使开发人员的生活更加轻松，因为要使构建在其计算机上正常工作，他们要做的就是复制任何内容。在构建机器上完成。