Microsoft（および大規模なインストールベースを持つ他のソフトウェア会社）は、パッチの依存関係をどのように管理しますか？

Question

マイクロソフトがコミュニティにリリースするOS（通常はセキュリティベース）のパッチとホットフィックスは、通常、一連の更新されたDLLまたはその他のバイナリで構成されます。

マイクロソフトやその他の企業は、ホットフィックスが互いに衝突しないことをどのように保証していますか？常に、1つの修正プログラムに以前の修正プログラムのすべての修正が含まれる累積的なパッチアプローチを採用していますか？多くのホットフィックスが特定の問題の修正に焦点を当てているように見えるため、これは事実とは思われません。焦点を当てた修正プログラムである場合、1つの修正プログラムが別の修正プログラムを破壊するのをどのように防止しますか（たとえば、互換性のないDLLが互いにインストールされる）。

このプロセスを管理するマイクロソフトの能力を常に賞賛してきました。私が勤務している会社ははるかに小さく、数年前にパッチプロセスに取り組んだとき、私たちは常に累積的なアプローチを採用しました。これは、次の「公式」までパッチのサイズが次第に大きくなることを意味していました。リリースが出ました。

パッチの依存関係を管理するためのいくつかの良い習慣は何ですか？

Answer 1

まず、Microsoft Windows Installerにはバイナリに直接パッチを適用する機能があります。ファイルの既知の以前の状態を考えると、既知の現在の状態にすることができます。以前は大規模な商用製品でこれを行っていましたが、2、3のリリース後、4ウェイシステムがパッチを作成するのに24時間以上かかりました-持っている（または持っている）場合は良くありませんナイトリービルド。

しばらくして、アップグレードのみを許可する累積修正を選択しました。下位レベルにいることを確認し、基本的に製品全体を交換します。 （とにかく、2番目または3番目の「デルタ」が基本的にすべてであるというケースもありました。）

Unix / Linuxでは、明らかにMSWIを使用できません。したがって、基本的に同じことを行う別のインストーラーを提供します。すべてのファイルを邪魔にならないように移動し、新品のようにインストールしてからバックアップを削除します。現実には、私たちのビジネスでは、これで十分です。私は、実際に電話をして不満を言うほど不幸な人々に私が気づいている苦情を受け取っていません（そして、それらの苦情は私の現在の仕事に基づいて非常に迅速に私を襲うでしょう）。ほとんどの場合、彼らはパッチで新しいレベルを取得して、実際のビジネスに取り掛かることを望んでいます。 奇妙なことに、彼らのビジネスはパッチをインストールしていません。