保持构建服务器更新的建议
作为一个经常在 QA、构建和操作之间切换的人，我不断遇到如何处理构建服务器上的操作系统更新的问题。在 Windows、Linux、MacOS 或任何其他可以通过互联网进行自我更新的操作系统上，这种二分法是相同的：
- QA 团队希望使构建服务器从产品发布周期开始到结束都保持原样，因为安装更新可能会破坏服务器的稳定性，并且意味着连续的构建不是根据相同的基线进行的。
- 运营团队希望将软件部署在安装了所有最新安全补丁的系统上；这可能意味着该软件未部署在与其构建的操作系统版本完全相同的操作系统上。
我通常通过以下方法来缓解这种情况：采用候选版本构建并将它们安装在具有完全最新操作系统的测试服务器上，重复在构建服务器上运行的自动化测试并进行一些额外的系统级测试以确保部署前一切看起来都很好。然而，这对我来说似乎效率很低；有人有更好的方法吗？
As a guy who frequently switches between QA, build and operations, I keep running into the issue of what to do about operating system updates on the build server. The dichotomy is the same on Windows, Linux, MacOS or any other o/s that can update itself via the internet:
- The QA team wants to keep the build server exactly as it is from the beginning of the product release cycle to the end, since installing updates could destabilize the server and means that successive builds aren't made against the same baseline.
- The ops team wants the software to be deployed on a system with all the latest security patches; this can mean that the software isn't deployed on exactly the same version of the o/s that it was built on.
I usually mitigate this by taking release candidate builds and installing them on a test server that has a completely up-to-date o/s, repeating the automated tests that are run on the build server and doing some additional system level testing to make sure everything looks good before deployment. However, this seems inefficient to me; does anyone have a better way ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
就我个人而言，我认为您在这里没有太大问题 - 只需将最新更新应用到构建服务器即可。我这样说的主要原因是：
您的代码或构建服务器上的任何依赖项与操作系统版本紧密耦合的可能性极小，以至于安装定期更新会影响任何事情，更不用说破坏它了。 Windows 版本之间的窗口消息等之间可能存在细微差别，但这些差异很少且相差很大，并且通常在互联网上有很好的记录。如果您使用 WPF/Silverlight 或 ASP.Net 等托管技术堆栈，甚至主要是 Winform，那么您将不受这些更改的影响 - 仅当您直接使用 WinAPI 来创建窗口或绘制窗口时，它们才会影响您。按钮。
始终针对最新版本的操作系统来设计您的产品是一个很好的做法，因为您需要鼓励您的客户也实现这些更新 - IOW，您不应该处于必须对客户说的位置不安装更新 xyz，因为您的应用程序不会针对它运行 - 特别是如果该更新是关键安全更新
，
测试操作系统版本之间的差异应该由 QA 团队完成，并且应该独立于构建服务器上的内容
您不希望构建服务器进入这样一种状态，即它与公司更新过程如此隔离，以至于当您最终应用它们时它呕吐并将熔化的硅喷得到处都是。 IOW，您等待更新的时间越长，出现问题并造成灾难性后果的风险就越高。小而频繁/增量更新的风险比每十年一次的大规模更新要低:)
您确实必须小心的构建服务器更新是第三方控件或库更新 - 它们经常包含重大更改或显着改变的行为。它们确实应该被安排好，然后进行一轮测试以寻找任何变化。
Personally i don't think you have much of an issue here - just apply the latest updates to the build server. The main reasons i say this are:
it is highly unlikely that your code or any of the dependencies on the build server are so tightly coupled to the OS version that installing regular updates is going to affect anything, let alone break it. There can be minor differences between window messages etc between Windows versions, but those are few and far between, and are usually quite well documented out there on teh interweb. If you are using managed technology stacks like WPF/Silverlight or ASP.Net and even mostly Winforms then you will be isolated from these changes - they should only affect you if you are doing hardcore stuff using the WinAPI directly to create your windows or draw your buttons.
it is a good practice to always engineer your product against the latest version of the OS, because you need to encourage your customer to implement those updates too - IOW you should not be in a position where you have to say to your client to not install update xyz because your application will not run against it - especially if that update is a critical security update
testing for differences between OS versions should be done by the QA team and should independant of what is on the build server
you do not want your build server to get in to such a state that it has been so isolated from the company update process that when you finally do apply them all it barfs and spits molten silicon everywhere. IOW, the longer you wait to update, the higher the risk of something going wrong and doing so catastrophically. Small and frequent/incremental updates are lower risk than mass updates once per decade :)
The build server updates that you do have to be cautious about are third party controls or library updates - they can frequently contain breaking changes or considerably altered behavior. They really should be scheduled, and followed up by a round of testing looking for any changes.
虚拟化！
使用 VMWare Server 等工具，您可以编写虚拟机启动和挂起的脚本。因此，您可以编写 VM 恢复脚本、SSH 来启动构建、复制、VM 挂起、重复。 （我这么说，但我放弃了这方面的工作。尽管如此，我当时仍在取得进展。）
此外，您可以信任您的操作系统供应商。你不能吗？
他们对兼容性感兴趣。如果您在 Windows XP 上构建，则几乎肯定可以在 XP SP3、Vista 和 Windows 7 上工作。
如果您在 RedHat Enterprise 5 上构建，它最好在 5.1、5.2、5.3、5.4 等上工作。
根据我的经验，这已经有效到目前为止对我来说还不错，我建议在最低补丁操作系统版本上进行构建。特别是对于 Linux 的东西，我发现更新的版本链接到旧版本上不可用的更新的库。
当然，在部署服务器的副本上测试代码并没有什么坏处。这完全取决于您想要的确定程度。
Virtualize!
Using stuff like VMWare Server you can script the launch and suspend of virtual machines. So you can script VM resume, SSH to launch build, copy, VM suspend, repeat. (I say this, but I abandoned my work on this. Still, I was making progress at the time.)
Also, you can trust your OS vendors. Can't you?
They have an interest in compatibility. If you build on Windows XP it is almost certain to work on XP SP3 and Vista and Windows 7.
If you build on RedHat Enterprise 5, it had better work on 5.1, 5.2, 5.3, 5.4, etc.
In my experience this has worked out OK so far for me and I recommend building on your lowest patch OS versions. With the Linux stuff in particular I have found newer releases linking to more recent libraries not available on older versions.
Of course it doesn't hurt to test your code on a copy of the deployment server. It all depends on how certain you want to be.
将构建服务器从网络上断开，这样您就无需担心安装安全更新。仅从 CD、拇指驱动器或任何其他方式加载源。
在发布周期结束时将其重新插入，然后进行所有更新。
Take the build server off the network, that way you do not need to worry about installing security updates. Only load the source from CD, thumb drive or whatever other means.
Plug it back in at the end of your release cycle and then let all the updates take place.
好吧，为了最稳定的过程，我将有两个构建服务器，“使用初始配置构建，使用更新配置构建”，以及两个具有类似差异的自动测试测试服务器。使用虚拟化可以有效且脚本化地完成此操作。
Well, for the most stable process, I would have two build servers, "Build with Initial config, Build with update config", and two autotest test servers with similar differences. Use virtualization to do this effectively and scriptably.