【问题标题】：Recommendations for keeping a build server updated保持更新构建服务器的建议
【发布时间】：2011-02-16 04:26:37
【问题描述】：

作为一个经常在 QA、构建和操作之间切换的人，我一直遇到如何处理构建服务器上的操作系统更新的问题。在 Windows、Linux、MacOS 或任何其他可以通过 Internet 自行更新的操作系统上，二分法是相同的：

我通常通过采用发布候选版本并将它们安装在具有完全最新 o/s 的测试服务器上来缓解这种情况，重复在构建服务器上运行的自动化测试并进行一些额外的系统级测试以确保在部署之前一切看起来都很好。但是，这对我来说似乎效率低下；有没有人有更好的方法？

【问题讨论】：

【解决方案1】：

就我个人而言，我认为您在这里没有什么问题 - 只需将最新更新应用到构建服务器即可。我这么说的主要原因是：

您的代码或构建服务器上的任何依赖项与操作系统版本紧密耦合的可能性极小，以至于安装定期更新会影响任何事情，更不用说破坏它了。 Windows 版本之间的窗口消息等之间可能存在细微差异，但这些差异很少而且相差甚远，并且通常在互联网上都有很好的记录。如果您使用 WPF/Silverlight 或 ASP.Net 等托管技术堆栈，甚至主要是 Winforms，那么您将与这些更改隔离 - 如果您直接使用 WinAPI 进行核心工作来创建窗口或绘制您的窗口，它们只会影响您按钮。
始终针对最新版本的操作系统设计您的产品是一种很好的做法，因为您需要鼓励您的客户也实施这些更新 - IOW 您不应该处于不得不说的位置提醒您的客户不要安装更新 xyz，因为您的应用程序不会针对它运行 - 尤其是如果该更新是关键的安全更新
测试操作系统版本之间的差异应该由 QA 团队完成，并且应该独立于构建服务器上的内容
您不希望您的构建服务器进入与公司更新过程如此隔离的状态，以至于当您最终将它们全部应用时，它会吐出并到处吐出熔融硅。 IOW，您等待更新的时间越长，出现问题并造成灾难性后果的风险就越高。与每十年一次的大规模更新相比，小而频繁/增量更新的风险更低 :)

您要做的构建服务器更新是第三方控件或库更新 - 它们经常包含重大更改或显着改变的行为。他们真的应该安排好，然后进行一轮测试以寻找任何变化。

【讨论】：

【解决方案2】：

虚拟化！

使用 VMWare Server 之类的东西，您可以编写启动和挂起虚拟机的脚本。因此，您可以编写 VM 恢复脚本、SSH 以启动构建、复制、VM 挂起、重复。（我这么说，但我放弃了这方面的工作。不过，我当时正在取得进展。）

此外，您可以信任您的操作系统供应商。不能吗？

他们对兼容性很感兴趣。如果您在 Windows XP 上构建，则几乎可以肯定可以在 XP SP3 和 Vista 以及 Windows 7 上运行。

如果您在 RedHat Enterprise 5 上构建，它最好在 5.1、5.2、5.3、5.4 等上运行。

根据我的经验，到目前为止，这对我来说还不错，我建议在您的最低补丁操作系统版本上进行构建。特别是在 Linux 方面，我发现较新的版本链接到较新的库，而这些库在旧版本中不可用。

当然，在部署服务器的副本上测试您的代码并没有什么坏处。这一切都取决于你想变得多么确定。

【讨论】：

我要补充一点，在构建服务器等大容量磁盘场景中，您应该为这些 VM 考虑真实（数据）磁盘而不是虚拟磁盘。我根据经验说话。
@Preet：根据我的经验，我没有发现磁盘访问存在问题。如果这是一个问题，那么我想在 Windows 上构建一个 tmpfs（在 Linux 上）或 RAM 磁盘将是答案。
编写虚拟服务器启动脚本的要点；我们已经为使用 Amazon EC2 的其他测试这样做了。
很可能是这样。不幸的是，我们注意到使用虚拟磁盘构建服务器的性能严重下降。假设构建没有优化磁盘 IO，但它可以。你能推荐一个像样的WINDOWS ram disk吗？我还没有遇到过引人注目的产品。
@Preet：我没有建议，因为我没有 IO 问题，但您应该检查 ServerFault 或 SuperUser。

【解决方案3】：

将构建服务器从网络中移除，这样您就无需担心安装安全更新。只能从 CD、拇指驱动器或任何其他方式加载源。

在发布周期结束时将其重新插入，然后进行所有更新。

【讨论】：

【解决方案4】：

嗯，对于最稳定的过程，我将有两个构建服务器，“使用初始配置构建，使用更新配置构建”，以及两个具有相似差异的自动测试测试服务器。使用虚拟化有效且可编写脚本地执行此操作。

【讨论】：