购买持续集成机器 - 关键因素？
我计划向我的（非常小的）公司提议购买一台计算机来运行持续集成。 如果他们说是，那么实际购买机器的任务可能会落在我身上，所以我的问题是：
我要在一台用于非常小的（3人）php团队持续集成的计算机中寻找什么？
哪些“东西”（内存、处理器等）重要，哪些不重要？
I'm planning to propose to my (very small) company that we buy a computer to run continous integration on. If they say yes, the task of actually buying the machine will probably fall on me, so my question is:
What do I look for in a computer that will be used for continuous integration for a very small (3 people) php team?
What "stuff" (memory, processor, etc.) are important, and what are not?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
当我们使用 Maven 时，存储成为我们的问题，Continuum 和 Clearcase并按小时建造。 每次构建后都会留下快照视图。
我们有一个足够强大的盒子 (Sun Fire V490)，并将其用于我们的开发集成环境和 Archiva 存储库。 所以我们从来没有真正遇到过任何性能和内存问题。 事实上，我们唯一一次遇到 PermGen 内存问题是在构建 Maven 站点目标时，这意味着使用 -XX:MaxPermSize=128m。
Storage became the issue for us when we were using Maven, Continuum and Clearcase and building hourly. The snapshot views were being left around after each build.
We had a powerful enough box (Sun Fire V490) and used it for our development integration environment and Archiva repository. So we never really had any issues with performance and memory. In fact the only time we had a problem with PermGen memory it was building the Maven site target and that just meant using -XX:MaxPermSize=128m.
你并不真的需要那么强大的机器。 如果您正在运行测试或其他指标，处理能力可能是您最关心的问题，但实际上您可以在旧的奔腾 1 上运行它，并且它可能会工作。
您的限制将是您的操作环境。 如果您正在运行 LAMP，您希望使用一台能够很好地处理 LAMP 设置的机器，这几乎是任何相当现代的 *nix 机器。
我在我们现有的一台旧 Pentium4 工作站上为 .NET 设置了持续集成设置，它处理得很好。
如果您在构建中归档代码，需要记住的一件事是存储空间。
You're not really going to need that powerful of a machine. If you are running tests or other metrics, processing ability is probably your primary concern but really you could run that on an old pentium 1 and it would probably work.
Your constraints are going to be your operating environment. If you are running LAMP you want to use a machine that can handle LAMP setup well which is pretty much any *nix machine that is fairly modern.
I set up a continuous integration setup for .NET on an old Pentium4 workstation we had laying around and it handled just fine.
One thing to keep in mind is storage space if you are archiving your code in the build.
您今天购买的几乎任何新机器都可以在不太大的源代码树上处理持续集成的任务。 需要注意的一些事项：
Pretty much any new machine you could buy today can handle the task of continuous integration on a not-too-large source tree. Some things to look for:
RAM：足以运行您的 CI 工具（phpUnderControl？）以及您想要的任何支持软件构建和测试。
存储：决定要在计算机上保留多少旧版本。 根据我的经验，保留太多是没有用的，尤其是。 如果您有一个小团队，没有很多回滚到旧版本的正式流程。
CPU：没问题。 您可以购买的任何机器都可以工作。
因此，在两者之间，我更倾向于 RAM 而不是存储空间。
RAM: enough to run your CI tool (phpUnderControl?) and whatever supporting software you want for your build and tests.
Storage: decide how many old builds you want to keep on the machine. In my experience it isn't useful to keep very many, esp. if you have small team w/out a lot of formal process for rolling back to older builds.
CPU: non-issue. Any machine you can buy will work.
So between the two I tend to favor RAM over Storage space.
除非应用程序很大，否则我只会得到一个双核盒子，大约有 4 GB 内存，可能还有 2 个相当快的 SATA 磁盘，设置为 RAID 0。也许是 500 GB？
如果您想真正安全地使用它，请为操作系统分区购买两个 70 多 GB 的 RAID 0 驱动器，然后在 RAID 5 中购买 3 140+ GB 的驱动器用于数据。
Unless the app is huge I'd just get a dual core box with about 4 gigs of ram and probably 2 reasonably fast SATA disks set in RAID 0. 500 Gigs maybe?
If you want to be really safe with it, get two 70ish gig drives for RAID 0 for the OS partition and then 3 140+ gig drives in RAID 5 for the data.
机器的性能并不重要，但要注意可用性，因为一旦您开始使用它，有一天魔法烟雾消失，您需要立即更换它才能继续工作。 定义合理的备份策略并确保您知道如何在必要时设置新的相同系统。 例如，您可能让它从一个小分区运行，您可以将其映像到另一台计算机中，然后如果数据的主要部分驻留在 RAID1 上并且至少一个驱动器可以工作（尽管在其他地方有可用的备份），则可以物理移动数据的主要部分网络上也有）。
The machine performance hardly matters, but take good care of availability because once you start using it and one day the magic smoke gets out, you need it replaced soon to continue working. Define a sensible backup policy and make sure you know how to set up a new identical system when necessary. For example, you might have it run from a small partition that you can image into another machine, and then the main part of the data can be physically moved if it resides on RAID1 and at least one drive works (though have a backup available elsewhere on the network as well).
我认为这里很多人都明白的一件事是，机器并不像 CI 软件那么重要。 机器唯一重要的时候是当你需要不同的架构时。 否则，请获取一台与您的目标环境相匹配的计算机。 如果您正在构建服务器应用程序，那么购买 64 位处理器可能是明智之举，因为您的应用程序可能会在 64 位服务器上运行。
我会更关心我使用哪个工具进行 CI。 您需要一些运行速度快的东西，正如这里的人指出的那样，它不应该保留旧版本，除非您需要它们可用。 如果是这样，我会寻找允许将构建和结果上传到单独服务器的东西。
I think one thing that a lot of people here are getting at is the machine isn't as important as the CI software. The only time the machine is important is if you need different architectures. Otherwise, get a machine that matches your target environment. If you are building a server app, it might be wise to get a 64bit processor since your app probably will be running on a 64bit server.
I would care more about which tool I'm usinging for CI. You need something that will run fast, and as people here have pointed out, it shouldn't hold onto the old builds unless you need them to be available. If so, I'd look for something that allows uploading builds and results to a separate server.
根据我的经验，这不一定是一台强大的机器。 您用于开发的任何机器都会非常令人满意。 显然，如果您对代码提交运行单元测试，机器越快，响应速度就越快。 我们的 CI 服务器运行的是 XP SP2、3G 处理器、3G RAM，它的性能远远无法满足我们目前的需求。 也就是说，很高兴在提交后 6 分钟内收到一封电子邮件，让您知道构建是否干净以及所有测试是否通过。 对于夜间构建，规格可能会降低更多，因为您可能有更多时间来完成这些工作。 硬盘空间（目前 300G 是可以实现的）非常适合存储报告和构建回归，但如果您有 NAS，您可能可以在构建后推迟工件。
From my experience, this does not have to be a powerhouse machine. Any machine you'd use for development would be more than satisfactory. Obviously, the faster the machine, the faster the response if you are running unit tests on code commits. Our CI server is running XP SP2, 3G processor, 3G of RAM, and it's way overpowered for our needs right now. That said, it's nice to get an email no more than 6 minutes after you commit that lets you know if the build is clean and all the tests pass. For doing nightly builds, the specs can probably go down more, as you probably have more time to get those done. Hard drive space (300G is reasonably attainable these days) is nice for storing reports and builds to regression, but if you have a NAS you can probably push off artifacts after they've been built.