Как Microsoft (и другие компании-разработчики программного обеспечения с большой установленной базой) управляют зависимостями исправлений?

Question

Исправления и исправления ОС (обычно основанные на безопасности), которые Microsoft выпускает для сообщества, обычно состоят из, как я понимаю, серии обновленных DLL или других двоичных файлов.

Как Microsoft и другим компаниям нравится, что исправления не конфликтуют друг с другом? Всегда ли они используют накопительный подход к исправлению, при котором одно исправление будет включать все исправления в предыдущих исправлениях? Это не кажется , потому что многие исправления, кажется, сосредоточены на устранении определенных проблем. Если они являются целенаправленными исправлениями, как они предотвращают удаление одного исправления другим (например, несовместимые библиотеки DLL устанавливаются друг с другом).

Я всегда восхищался способностью Microsoft управлять этим процессом. Компания, в которой я работаю, гораздо меньше, и когда я работал над процессом исправлений несколько лет назад, мы всегда придерживались кумулятивного подхода, когда один патч немедленно заменял все предыдущие патчи, основанные на этом выпуске. Это означало, что размеры патчей постепенно увеличивались, пока не вышел следующий «официальный» релиз.

Каковы хорошие практики для управления зависимостями исправлений?

Answer 1

Во-первых, установщик Microsoft Windows имеет возможность напрямую исправлять двоичные файлы. Учитывая известные ранее состояния файла, он может привести их к известному текущему состоянию. Раньше мы делали это для нашего крупного коммерческого продукта, но после нескольких выпусков нашим четырехпроцессорным системам потребовалось более 24 часов для создания патча - что не очень хорошо, когда у вас есть (или вы хотите иметь) ночные сборки.

Через некоторое время мы выбрали кумулятивные исправления, в которых мы просто разрешили обновления. Мы проверяем, что вы на более низком уровне, а затем в основном заменяем весь продукт. (У нас также был случай, когда вторая или третья «дельта» была в основном всем чем угодно.)

В Unix / Linux мы не можем использовать MSWI, очевидно, поэтому мы предоставляем другой установщик, который в основном делает то же самое: убирает все файлы с пути, устанавливает, как будто новый, а затем удаляет резервную копию. Реальность такова, что для нас в нашем бизнесе этого достаточно. Мы не получили ни одной жалобы, о которой я знаю (и эти жалобы довольно быстро меня поразят, исходя из моей текущей работы), когда люди были достаточно недовольны, чтобы действительно звонить и жаловаться. В основном, они хотят получить более новый уровень с патчами, чтобы они могли продолжать свой реальный бизнес. Как ни странно, их бизнес не устанавливает патчи.