Microsoft（以及其他拥有大量安装基础的软件公司）如何管理补丁依赖性？
据我所知，微软向社区发布的操作系统（通常是基于安全的）补丁和修补程序通常由一系列更新的 DLL 或其他二进制文件组成。
Microsoft 和其他类似公司如何确保修补程序不会相互冲突？ 他们是否总是采用累积补丁方法，即单个修补程序将包含以前修补程序中的所有修补程序？ 事实似乎并非如此，因为许多修补程序似乎都专注于解决特定问题。 如果它们是重点修补程序，它们如何防止一个修补程序破坏另一个修补程序（例如，彼此安装不兼容的 DLL）。
我一直很钦佩微软管理这个流程的能力。 我工作的公司规模要小得多，几年前当我从事补丁流程时，我们总是采用累积方法，即单个补丁立即取代基于该版本的所有先前补丁。 这意味着补丁的大小逐渐变大，直到下一个“官方”版本发布。
管理补丁依赖关系有哪些好的做法？
OS (usually security-based) patches and hotfixes that Microsoft releases to the community normally consist of, in my understanding, a series of updated DLLs or other binaries.
How does Microsoft, and other companies like it, ensure that that hotfixes don't clash with each other? Do they always go for a cumulative patch approach, where a single hotfix will includes all of the fixes in previous hotfixes? This doesn't seem to be the case, because many hotfixes seem to be focused on fixing specific problems. If they are focused hotfixes, how do they prevent one hotfix from trashing another one (e.g. incompatible DLLs being installed with each other).
I have always admired Microsoft's ability to manage this process. The company I work for is much smaller, and when I worked on the patch process a few years ago, we always went for the cumulative approach, where a single patch immediately superseded all previous patches based on that release. This meant that the patches got progressively larger in size, until the next "official" release came out.
What are some good practices for managing patch dependencies?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先，Microsoft Windows Installer 能够直接修补二进制文件。 给定文件的已知早期状态，它可以将它们带到已知的当前状态。 我们曾经为我们的大型商业产品这样做，但在几次发布之后，我们的四路系统需要长达 24 小时才能生成补丁 - 当您拥有（或想要拥有）时，这并不好每晚构建。
一段时间后，我们选择了累积修复，只允许升级。 我们检查你的水平较低，然后基本上更换整个产品。 （我们也遇到过第二个或第三个“delta”基本上就是一切的情况。）
在 Unix/Linux 上，显然我们不能使用 MSWI，所以我们提供了另一个安装程序，它基本上做同样的事情：移动所有文件不碍事，像全新一样安装，然后删除备份。 现实是，对于我们的业务来说，这已经足够了。 据我所知，我们还没有收到任何投诉（根据我目前的工作，这些投诉很快就会打击到我），而人们不满意，会打电话来投诉。 大多数情况下，他们希望通过补丁获得更新的级别，以便他们可以继续他们的实际业务。 奇怪的是，他们的业务不是安装补丁。
First off, Microsoft Windows Installer has the ability to patch binaries directly. Given known earlier states of a file, it can bring them to a known current state. We used to do this for our Large Commercial Product, but after a couple of releases, it was taking upwards of 24 hours for our four-way systems to produce a patch - which isn't good when you have (or want to have) nightly builds.
After a while, we opted for cumulative fixes where we merely allowed upgrades. We check that you're at a lower level, and then basically replace the entire product. (We also had the case whereby the second or third "delta" was basically everything anyway.)
On Unix/Linux, we can't use MSWI, obviously, so we provide another installer which basically does the same thing: move all the files out of the way, install as if brand new, and then delete the backup. The reality is, for us in our business, this is sufficient. We haven't gotten any complaints that I'm aware of (and those complaints would hit me pretty quickly based on my current job) with people unhappy enough to actually call in and complain. Mostly, they want to get the newer level with the patches so they can get on with their real business. Oddly enough, their business isn't installing patches.