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

Question

Microsoft がコミュニティにリリースする OS (通常はセキュリティ ベース) のパッチとホットフィックスは、通常、一連の更新された DLL またはその他のバイナリで構成されていると理解しています。

Microsoft やその他の企業は、修正プログラムが互いに衝突しないようにどのように保証していますか? 単一の修正プログラムに以前の修正プログラムのすべての修正が含まれる、累積的な修正プログラムのアプローチを常に採用していますか? 多くの修正プログラムは特定の問題の修正に重点を置いているように見えるため、これは当てはまらないようです。それらが焦点を絞った修正プログラムである場合、ある修正プログラムが別の修正プログラムを破壊するのをどのように防止しますか (たとえば、互換性のない DLL が互いにインストールされているなど)。

私は常に、このプロセスを管理する Microsoft の能力に感心してきました。私が働いている会社はずっと小規模で、数年前にパッチ プロセスに取り組んだときは、常に累積的なアプローチを採用していました。つまり、単一のパッチが、そのリリースに基づく以前のすべてのパッチに即座に取って代わりました。これは、次の「公式」リリースが公開されるまで、パッチのサイズが徐々に大きくなることを意味していました。

パッチの依存関係を管理するための良い方法は何ですか?

Answer 1

まず、Microsoft Windows インストーラーには、バイナリに直接パッチを適用する機能があります。ファイルの既知の以前の状態が与えられると、それらを既知の現在の状態にすることができます。以前は大規模な商用製品でこれを行っていましたが、数回のリリースの後、4 方向システムがパッチを作成するのに 24 時間以上かかっていました。夜間ビルド。

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

Unix/Linux では、明らかに MSWI を使用できないため、基本的に同じことを行う別のインストーラーを提供します。すべてのファイルを移動し、新しいものとしてインストールし、バックアップを削除します。現実には、私たちのビジネスではこれで十分です。私が知っている苦情はありませんでした (そして、私の現在の仕事に基づいて、これらの苦情はすぐに私を襲ったでしょう) 実際に電話して苦情を言うほど不満を持っている人々から. ほとんどの場合、彼らはパッチで新しいレベルを取得して、実際のビジネスを継続できるようにしたいと考えています。 奇妙なことに、彼らのビジネスはパッチのインストールではありません。