Microsoft(以及具有大量安装基础的其他软件公司)如何管理补丁依赖项？

Question

Microsoft发布到社区的操作系统(通常是基于安全性的)修补程序和修补程序通常由我理解的一系列更新的DLL或其他二进制文件组成.

Microsoft和其他类似公司如何确保这些修补程序不会相互冲突？他们是否总是采用累积修补程序方法,其中单个修补程序将包含以前修补程序中的所有修补程序？这并不似乎是这种情况,因为许多修补程序似乎集中在固定的具体问题.如果它们是重点修补程序,它们如何防止一个修补程序丢弃另一个修补程序(例如,彼此安装不兼容的DLL).

我一直钦佩微软管理这个过程的能力.我工作的公司要小得多,而且几年前我在修补程序上工作时,我们总是采用累积方法,其中一个补丁立即取代所有先前基于该版本的补丁.这意味着补丁的大小逐渐变大,直到下一个"官方"版本发布.

管理补丁依赖项有哪些好的做法？

Answer 1

首先，Microsoft Windows Installer 能够直接修补二进制文件。给定文件的已知早期状态，它可以将它们带到已知的当前状态。我们曾经为我们的大型商业产品这样做，但在几次发布之后，我们的四路系统需要长达 24 小时才能生成补丁 - 当您拥有（或想要拥有）时，这并不好每晚构建。

一段时间后，我们选择了累积修复，只允许升级。我们检查你的水平较低，然后基本上更换整个产品。（我们也遇到过第二个或第三个“三角洲”基本上就是一切的情况。）

在 Unix/Linux 上，显然我们不能使用 MSWI，因此我们提供了另一个安装程序，它基本上做同样的事情：将所有文件移开，像全新的一样安装，然后删除备份。现实是，对于我们的业务来说，这已经足够了。据我所知，我们还没有收到任何投诉（根据我目前的工作，这些投诉很快就会打击我），人们不满意，可以实际打电话投诉。大多数情况下，他们希望通过补丁获得更新的级别，以便他们可以继续他们的实际业务。 奇怪的是，他们的业务不是安装补丁。