windows - 保持构建服务器更新的建议

Question

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

• QA 团队希望构建服务器从产品发布周期开始到结束始终保持原样，因为安装更新可能会破坏服务器的稳定性，并且意味着后续构建不是基于相同的基线进行的。
• 运营团队希望将软件部署在安装了所有最新安全补丁的系统上；这可能意味着该软件未部署在与构建它的操作系统完全相同的版本上。

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

Answer 1

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

• 您的代码或构建服务器上的任何依赖项不太可能与操作系统版本紧密耦合，以至于安装定期更新会影响任何东西，更不用说破坏它了。 Windows 版本之间的窗口消息等之间可能存在细微差异，但这些差异很少而且相差甚远，并且通常在互联网上有很好的记录。如果您使用的是托管技术堆栈，如 WPF/Silverlight 或 ASP.Net，甚至主要是 Winforms，那么您将与这些更改隔离开来——只有当您直接使用 WinAPI 来创建您的窗口或绘制您的窗口时，它们才会影响您。按钮。

• 始终针对最新版本的操作系统设计您的产品是一个很好的做法，因为您需要鼓励您的客户也实现这些更新 - IOW 您不应该处于必须说的位置告诉您的客户端不要安装更新 xyz，因为您的应用程序不会针对它运行 - 特别是如果该更新是关键安全更新

• 测试操作系统版本之间的差异应该由 QA 团队完成，并且应该独立于构建服务器上的内容

• 您不希望您的构建服务器进入这样一种状态，即它与公司更新过程如此隔离，以至于当您最终应用它们时，它会呕吐并到处吐出熔化的硅。 IOW，您等待更新的时间越长，出现问题并造成灾难性后果的风险就越高。与每十年一次的大规模更新相比，小而频繁/增量更新的风险更低:)

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