作为经常在QA，构建和操作之间切换的人，我一直在讨论如何在构建服务器上进行操作系统更新。 Windows，Linux，MacOS或任何其他可以通过互联网更新自己的o / s的二分法是相同的：
我通常通过获取候选版本并将其安装在具有完全最新o / s的测试服务器上来重复此操作，重复在构建服务器上运行的自动化测试并进行一些额外的系统级测试在部署之前确保一切看起来都很好。然而，这对我来说似乎效率低下;有没有人有更好的方法？
答案 0 :(得分：3)
我个人认为你没有太多问题 - 只需将最新的更新应用到构建服务器。我这说的主要原因是：
您的代码或构建服务器上的任何依赖项与OS版本紧密耦合的可能性很小，因此安装常规更新会影响任何事情，更不用说破坏它了。 Windows版本之间的窗口消息等之间可能存在细微差别，但这些差异很小，而且通常在网络间很好地记录。如果您使用的是托管技术堆栈，如WPF / Silverlight或ASP.Net，甚至大多数是Winforms，那么您将与这些更改隔离 - 如果您正在使用WinAPI直接创建窗口或绘制您的硬核内容，它们应该只会影响您的按钮。
最好始终针对最新版本的操作系统设计您的产品，因为您需要鼓励您的客户实施这些更新 - 如果您不应该处于您必须说的位置到您的客户端不安装更新xyz，因为您的应用程序不会针对它运行 - 特别是如果该更新是关键安全更新
测试OS版本之间的差异应由QA团队完成，并且应独立于构建服务器上的内容
您不希望您的构建服务器进入这样一种状态，即它与公司更新过程如此隔离，以至于当您最终将它们全部应用到barfs并随处吐出熔化的硅时。 IOW，等待更新的时间越长，出现问题的风险就越大，灾难性地发生。小而频繁/增量更新的风险低于每十年一次的大量更新：）
构建服务器更新做必须谨慎对待第三方控件或库更新 - 它们经常包含重大更改或显着更改的行为。他们确实应该安排，然后进行一轮测试，寻找任何变化。
答案 1 :(得分：1)
使用VMWare Server之类的东西，您可以编写启动和暂停虚拟机的脚本。因此，您可以编写VM恢复脚本，SSH以启动构建，复制，VM挂起，重复。 （我说这个，但我放弃了我的工作。但是，我当时正在取得进展。）
此外，您可以信任您的操作系统供应商。不是吗？
他们对兼容性感兴趣。如果你在Windows XP上构建，几乎可以肯定它可以在XP SP3，Vista和Windows 7上运行。
如果你在RedHat Enterprise 5上构建，它可以更好地处理5.1,5.2,5.3,5.4等。
根据我的经验，这对我来说已经很好了，我建议在你的最低补丁操作系统版本上构建。特别是Linux的东西，我发现更新的版本链接到旧版本不具备的最新库。
当然，在部署服务器的副本上测试代码并没有什么坏处。这一切都取决于你想要的确定程度。
答案 2 :(得分：1)
将构建服务器从网络中移除，这样您就不必担心安装安全更新。仅从CD，拇指驱动器或其他任何方式加载源。
在发布周期结束时将其重新插入，然后进行所有更新。
答案 3 :(得分：1)
嗯，对于最稳定的流程，我会有两个构建服务器，“使用初始配置构建，使用更新配置构建”和两个具有类似差异的自动测试服务器。使用虚拟化可以有效且可编写脚本。