在MSDN site,它声明:
好的,我明白了。但我的经理没有,我无法说服他。“...在专用于运行构建的计算机上安装Team Foundation Build。”
通过这种方式,我请求SO社区帮助我说服他需要使用专用计算机来运行构建。
答案 0 :(得分:8)
构建是一个CPU密集型过程。构建服务器的想法是它坐在那里并在每次签入后构建,以确保没有任何损坏。如果你把它放在带有其他资源的计算机上,它会减慢其他一切。即使你虚拟化它,也可能会出现问题。
另一件事是你想要一个“干净”的操作系统安装,以便其他程序不会通过添加客户端计算机可能没有的依赖项来污染计算机。
如果您只将它用于夜间构建,我认为您可以运行虚拟机来执行此操作。
答案 1 :(得分:4)
在他的PC上设置构建服务器,然后将其用于持续集成构建,直到他理解为什么需要自己的服务器;)
在他给你的硬件供应商打电话给我一个新服务器之前,我给它一个小时。
答案 2 :(得分:2)
对于一个可重现的环境,将不再听到短语“但它在我的机器上工作”。它可以减轻开发人员的负担,确保每个人都是最新的,并且所有内容都已经过检查。
Joel Spolskys article可能对您有用(稍微超过他谈论每日构建服务器的中间位置)。
This question还有几个答案。
答案 3 :(得分:1)
您还可以包含构建后自动运行的测试,包括单元测试和性能测试。系统可以配置为导出功能完备的安装程序,该安装程序可以在Intranet上使用,供其他部门下载和使用/测试。如果你必须每周或每月都这样做,这可以节省大量的时间和金钱。
如果您在每次有人检查更改时将构建服务器配置为重建,那么如果所有内容都实际构建或者某些内容已被搞砸,您将获得即时答案。
答案 4 :(得分:1)
您希望构建尽可能快地运行,特别是如果您正在进行持续集成或者您有大型构建过程。我们最近开始与我们的IT部门打架,因为我们用于构建和测试的服务器变得太慢了。这主要是因为他们都将它们作为虚拟机运行,并且每个主机的虚拟机数量太多。我们完整的构建过程(不是CI构建)现在需要花费半个多小时才能运行(大部分是部署,而不是编译),并且它会杀死我们的QA人员,因为他们必须等待太长时间才能构建。
获取构建过程运行所需的时间(以小时为单位),将其乘以每年运行的次数,然后将其乘以等待构建完成的人员的每小时费率。在我们的组织中,这是数万美元。它确实可以在构建机器上花一点钱。
答案 5 :(得分:0)
我认为应该将服务器设计为执行特定任务。例如,Active Directory控制器不应该兼作SQL服务器。
从可用资源的角度来看,很难平衡多个服务器应用程序之间的负载。例如,执行构建的构建服务器会影响该框上任何其他服务的性能。您的构建服务器可能会用于构建许多不同的项目。编译和与典型构建相关的大量任务(例如,代码分析,单元测试等)是昂贵的,并且CPU /磁盘密集型操作。
此外,你有没有注意到你的桌面如何变得更慢,更不稳定?这通常是由于您安装的应用程序数量。添加的依赖项和增加的内存消耗将对服务器的可靠性产生负面影响。
服务器应保持干净,并且设计为在尽可能少的中断的情况下执行其特定任务。
答案 6 :(得分:0)
作为练习,请问经理哪种机器适合作为构建服务器?他的机器?另一个开发者的机器?在开发人员的盒子上运行该过程的成本会很差。
为了论证,让我们允许开发人员在他/她的机器上运行它。对于没有构建机器,这仍然可能是一个积极的因素。
在短时间内我怀疑经理和团队会意识到需要一台新机器。
尽管其他人引用了Spolsky文章,但构建机器不一定是最快的盒子......它可以是一个抛弃的二手机器。
一旦团队看到并体验构建服务器的好处,他们就可以自然地跳转到专用机器。 (如果他们没有,那么是时候运行了)
它的一些具体原因(正如其他人所说)
构建的可重现性和稳定性。构建必须一致且可重复。对构建服务器的控制远远超过所有各种开发人员机器。这允许开发人员在不影响发布/构建的情况下尝试Beta开发工具等。
效率 - 使用专用的构建服务器可以为开发人员释放开发人员计算机的CPU。
答案 7 :(得分:0)
"Continuous Integration"对您的经理有意义吗?这将是我的建议,因为这是拥有专用构建机器的主要原因,它也可以保留代码库以供另一台机器使用。