Microsoft hotfix: скачивание и установка
В этой статье вы узнаете, что такое хотфикс, как правильно его запросить, скачать и установить.
Общая информация
Хотфиксы (hotfix дословно – «горячее исправление») содержат исправления неполадок в работе операционной системы или небольшие дополнения к функциям Windows. Иногда хотфиксы представляют собой тестовые версии будущих обновлений системы. Как правило, хотфикс предназначен для решения конкретной проблемы или задачи и должен устанавливаться только в случаях явной необходимости. Каждый хотфикс предназначен строго для определенной версии Windows.
Хотфиксы распространяются в самораспаковывающихся ZIP-архивах, могут быть скачаны с сайта поддержки Microsoft и только по запросу с указанием email. Для распаковки архива необходимо ввести пароль, который автоматически высылается на email после запроса хотфикса.
Скачивание и установка хотфикса
1. Перейдите на страницу запроса хотфикса.
2. Прочтите условия соглашения и примите его.
3. Выберите свою версию Windows 7/Windows Server 2008 R2, введите свой адрес email и нажмите кнопку Запросить исправление.
4. На указанный email придет письмо «Запрошенная ссылка для загрузки исправления», со ссылкой на скачивание архива с хотфиксом. Также в этом письме содержится пароль для распаковки архива.
6. Дважды щелкните по скачанному архиву, нажмите Continue и укажите папку, в которую нужно распаковать хотфикс.
7. Введите пароль для распаковки.
8. Откройте папку с распакованным хотфиксом, запустите исполняемый файл с номером исправления.
9. Согласитесь на установку обновления.
10. Перезагрузите компьютер.
Если условия запроса или установки хотфиксов изменились, пожалуйста, сообщите об этом в комментариях.
Зачем и как мы пишем постмортемы по критичным багам
В какой-то момент у нас стало много хотфиксов — стабильно больше половины деплоев на проде были хотфиксы или откаты. Мы решили анализировать каждый хотфикс, чтобы понять причины, найти системные закономерности и устранить их, не допуская два раза одних и тех же ошибок. Как говорил Джейсон Стейтем (Стэтхэм? Стэтэм?): «Не страшно ошибаться, страшно повторять одну ошибку 2 раза». Ну и мы решили не повторяться. В статье расскажу как мы анализируем хотфиксы и другие критичные проблемы, что у нас получается, а что нет, с какими сложностями столкнулись и как их решали.
Как было раньше
Раньше на проде случались хотфиксы-откаты из-за критичных багов. Мы в QA понимали что нам нужно проводить какую-то ретроспективу по пропущенным багам на прод. Поэтому после каких-то очень проблемных релизов:
собирались и обсуждали проблему;
звали разработчиков, участвующих в этом релизе;
принимали решения (некоторые работают до сих пор).
Основная проблема при таком подходе, что ты не разбираешь каждый хотфикс или откат детально. Ты обращаешь внимание только на очень критичные проблемы. Такая активность не системная.
Когда хотфиксов стало много (примерно половина всех выкладок на прод были хотфиксы) поняли, что этого недостаточно — нужно что-то менять. Мы решили попробовать практику написания постмортемов на хотфиксы и откаты.
Что такое постмортем?
Вообще, постмортем — это посмертная фотография родственников.
Мы узнали об этой практике у нашей команды Платформы. Они уже с 2018 года ведут постмортемы по всем инцидентам в системе.
Постмортем для примера.
Наши люди даже выступали с этими темами на конференциях.
В этом подходе детально разбирается каждый инцидент, вырабатываются экшен айтемы (action items) для устранения и недопущения проблем. Мне этот инструмент показался черезвычайно полезным и мы решили попробовать адаптировать его под наши нужды.
Как начали вести
Мы почитали о практике ведения постмортемов, чтобы не допустить критичных ошибок при их написании. Пошли в репозиторий с постмортемами от команды Платформы, почитали их постмортемы и на основании их шаблона сделали свой (шаблон будет в конце статьи).
Вначале мы вели постмортемы в Nuclino. Но в нём сложно трекать статус каждого постмортема, выполняемость решений и т.д. и т.п. А вот в Kaiten наглядно видно текущий статус постмортема, какие из них без решений, можно строить какие-то отчеты. Поэтому наши постмортемы логично переехали туда.
Скрин с Kaiten.
Чуть поработали и поняли, что у нас есть несколько типов критичных проблем и под каждый из типов создали свой шаблон: некоторые вопросы были актуальны для одного типа, но неактуальны для другого. В итоге получилось 4 типа постмортемов:
По хотфиксам на проде.
По откатам релизов.
По «подливкам» в релиз — когда в релизную ветку подливают фиксы. Иногда на этапе прогона тестов находятся критичные баги. Если бы они попали на прод был бы хотфикс, иначе их бы пофиксили стандартным флоу в следующем релизе.
По STL (Stop the Line). Подробнее что это такое можно почитать в статье «Stop the line или прокачай свой pipeline, йоу»
Пример шаблона для хотфиксов из Kaiten.
Структура и способ ведения
В этом разделе расскажу о структуре шаблона на примере постмортема для хотфиксов. Возьмем один из недавних постмортемов, когда мы делали хотфикс.
Пишем дату хотфикса. Не всегда карточки создаются в тот же день, что и постмортем, поэтому решили проставлять дату случившегося события. Трекинг длительности исправления задач делает Kaiten и выдает нам в отчете. Кроме этого по дате инцидента можно сделать более глубокий анализ, посмотреть частотность по темам, выявить закономерности.
Авторы постмортема. Знаем к кому идти за подробностями инцидента или с уточняющими вопросами по решению. Наличие авторов постмортема не противоречит принципу написания постмортемов «blameless culture». Мы не обвиняем никого в доведении до проблемы, а хотим лишь отобразить участников разбора.
Причины. В этом блоке описываем причину которая привела к хотфиксу, что с технической точки зрения произошло. Стараемся выяснить корневые причины случившегося.
Проблемы. Пишем о том, с какими проблемами могли столкнуться наши пользователи. Какую функциональность мы задели, какие непотребства видели наши пользователи. Или что видели мы, если мы заметили проблему раньше пользователей (алерты, подскочившие графики в Grafana).
Потери. В этом блоке пишем влияние на бизнес, сколько задето пиццерий или пользователей, сколько потеряли в деньгах или во времени (это импакт на пользователей).
Что делать, чтобы ситуация не повторилась. В этом блоке пишем, что можно сделать чтобы не допустить эту проблему в будущем — решения, которые позволят на ранних стадиях заметить проблему или вообще устранить.
Разное. Это поле добавили как свободный ответ в анкетах, вдруг какая-то важная мысль не уложится в заданный нами шаблон. Иногда его заполняют, иногда нет.
Шаблон
Здесь оставлю пример шаблона наших постмортемов без моих комментариев.
## Последствия для бизнеса
## Предложения по недопущению в будущем
## Как можно было избежать проблемы (представь что у тебя есть машина времени и ты вернулся к моменту, когда ты еще не написал этот код, что можно было сделать, чтобы не было хотфикса)
**Создать картохи на написание _автотеста_ по этой проблеме в своем бэклоге и прикрепи их сюда как дочерние**
**Создать картохи по _недопущению хотфикса_ в будущем в своем бэклоге или бэклоге владельцев компонента и прикрепи их сюда как дочерние**
## Что ещё хочется добавить
**Не забудь поставить теги компонента в котором случилась проблема**
Берите себе, адаптируйте и пользуйтесь.
Сложности и как их решали
С «нахрапа» не получилось ввести постмортемы и вести их идеально. Вот наш список проблем.
Не заполняли постмортемы. Банально — да: поначалу люди ответственные за релиз забывали заполнять постмортемы…
Решили проблему добавив в чек-лист «релизмена» пункт о необходимости заполнения постмортема. «Релизмен» — разработчик отвечающий за выкатку релиза, ротируется после каждого релиза.
И проблема решилась. Остались единичные случаи, когда постмортем не заполняется. В таком случае в ручном режиме «тыкаем» ответственного и просим его заполнить. Владелец и хранитель процесса — QA-гильдия.
Не предлагали решений или предлагали слабые решения. Сейчас основная проблема в том, что почти в половине постмортемов нет решений или они очень общие типа «распилить монолит», «тестировать перед мержом в дев», «писать код без багов, а с багами не писать».
Проблему решили припиской в чек-листе, что когда QA пишет постмортем, он должен позвать другого QA. Мы прямо в процессе написания постмортема можем дать обратную связь о слабом решении или вообще о его отсутствии. Либо после написания постмортема нам отправляют его на ревью и мы так же даем обратную связь только уже асинхронно.
Скрин с чек-листа.
Не создавали карточки на решение проблем. Мы используем Kaiten и настроили доски так:
прикреплённая дочерняя карточка с устранением проблемы берется в работу;
постмортем автоматически переезжает в «In progress»;
когда задачу завершают — завершается и постмортем.
Это помогает не мониторить исполнение постмортемов.
Поначалу карточки не создавались, а даже если создавались, то не прикреплялись как дочерние и постмортемы не двигались. Решили тоже просто добавив в шаблон пометку о том, что нужно создать карточку и прикрепить её как дочернюю.
Решения долго берут в работу. Мы все понимаем, что бэклогом владеет продакт и у него есть приоритеты. Мы понимаем, что когда команда берёт техзадачи в спринт, это зависит от множества факторов: понимания продактом важности этих технических задач и последствий (если их не решить), от зрелости самой команды, критичности сервиса и проблемы. Но проблема всё равно болезненная.
Мы провели небольшую аналитику по среднему времени ожидания постмортема до момента когда над ним начали работу. Получилось, что медианное время ожидания постмортема до взятия в работу меньше месяца — 21 календарный день. По результатам навесили на колонку напоминание: когда карточка висит в ToDo дольше, она начинает привлекать к себе внимание.
Когда появляется сигнал мы идем к команде, которая должна решить эту проблему и спрашиваем о судьбе этой карточки. Иногда они становятся неактуальными, это тоже нормально.
Случаются повторные ошибки. У нас была ситуация, когда невыполненное решение одного из постмортемов привело к другому постмортему. Одним из решений когда-то было написать и прогонять нагрузочные тесты на роль Менеджер смены. Команда нагрузочного тестирования не успела взять её в работу и мы словили критичный баг на проде, который можно было бы обнаружить на нагрузочных тестах.
Результаты в цифрах
Мы проанализировали постмортемы за пол года, и вот какая картина получается.
Треть наших постмортемов не имеют конкретных решений на доработку и недопущение проблем в будущем.
Половина наших постмортемов в которых есть конкретные решения ещё не выполнена.
49 дней — медианное время жизни постмортема от появления на доске до выполнения (из тех что выполнили и в которых были решения), а среднее — 82 дня. Такие различия обусловлены большим разбросом значений. Критичные решения или очень простые решаются достаточно быстро, сложные и не критичные могут долго провисеть в ожидании.
Ситуация не радужная, но благодаря ведению этих постмортемов мы знаем о проблеме и можем предпринимать действия по её улучшению.
Выводы
Наше следующее направление по работе с постмортемами после обсуждения на гильдии — сфокусироваться на том, чтобы повысить процент постмортемов, в которых было какое-либо решение.
Мы решили сконцентрироваться на постмортемах без экшен айтемов. Моя первая мысль была: «Не лучше ли фокусироваться на выполнении постмортемов?». Однако, после некоторого обсуждения на комьюнити, мы пришли к выводу, что если пишется постмортем — то должен быть экшен айтем, иначе это «бесполезная работа». Поэтому мы решили увеличить этот процент, а после его увеличения взяться за повышение исполняемости этих постмортемов.
Ведение постмортемов по критичным функциональным багам на проде мне кажется полезной практикой. Мы явно проговариваем и анализируем каждую проблему, которую не хотим больше повторять. Мы получаем конкретные решения каждой проблемы. И в целом наша система становится лучше и меньше подвержена ошибкам.
Что ещё почитать.
Подписывайтесь на чат Dodo Engineering, если хотите обсудить эту и другие наши статьи и подходы, а также на канал Dodo Engineering, где мы постим всё, что с нами интересного происходит. А ещё есть группа в ВК (ну мало ли).
Hotfix что это за программа
Подлинный файл является одним из компонентов программного обеспечения Hotfix Installer, разработанного Microsoft.
Hotfix.exe — это исполняемый файл (программа) для Windows. Расширение имени файла .exe — это аббревиатура от англ. слова executable — исполнимый. Необходимо запускать исполняемые файлы от проверенных производителей программ, потому что исполняемые файлы могут потенциально изменить настройки компьютера или нанести вред вашему компьютеру. Бесплатный форум с информацией о файлах может помочь вам разобраться является ли hotfix.exe вирусом, трояном, программой-шпионом, рекламой, которую вы можете удалить, или файл принадлежит системе Windows или приложению, которому можно доверять.
Вот так, вы сможете исправить ошибки, связанные с hotfix.exe
Информация о файле hotfix.exe
Процесс Hotfix Installer принадлежит программе Microsoft SQL Setup от Microsoft (www.microsoft.com).
Описание: hotfix.exe не является необходимым для Windows. Файл hotfix.exe находится в подпапках диска C:. Размер файла для Windows 10/8/7/XP составляет 2,539,872 байт. 
У процесса нет видимого окна. Сертифицировано надежной компанией. Это не системный файл Windows. Hotfix.exe способен мониторить приложения. Поэтому технический рейтинг надежности 36% опасности.
Если hotfix.exe находится в подпапках «C:UsersUSERNAME», тогда рейтинг надежности 74% опасности. Размер файла 895,488 байт. Нет описания файла. Приложение не видно пользователям. Процесс использует порт, чтобы присоединится к сети или интернету. Это не файл Windows. Hotfix.exe способен записывать ввод данных и мониторить приложения.
Важно: Некоторые вирусы маскируют себя как hotfix.exe, особенно, если они расположены в каталогах c:windows или c:windowssystem32. Таким образом, вы должны проверить файл hotfix.exe на вашем ПК, чтобы убедиться, что это угроза. Мы рекомендуем Security Task Manager для проверки безопасности вашего компьютера.
Комментарий пользователя
Лучшие практики для исправления проблем с hotfix
Аккуратный и опрятный компьютер — это главное требование для избежания проблем с hotfix. Для этого требуется регулярная проверка компьютера на вирусы, очистка жесткого диска, используя cleanmgr и sfc /scannow, удаление программ, которые больше не нужны, проверка программ, которые запускаются при старте Windows (используя msconfig) и активация Автоматическое обновление Windows. Всегда помните о создании периодических бэкапов, или в крайнем случае о создании точек восстановления.
Если у вас актуальные проблемы, попробуйте вспомнить, что вы делали в последнее время, или последнюю программу, которую вы устанавливали перед тем, как появилась впервые проблема. Используйте команду resmon, чтобы определить процесс, который вызывает проблемы. Даже если у вас серьезные проблемы с компьютером, прежде чем переустанавливать Windows, лучше попробуйте восстановить целостность установки ОС или для Windows 8 и более поздних версий Windows выполнить команду DISM.exe /Online /Cleanup-image /Restorehealth. Это позволит восстановить операционную систему без потери данных.
Следующие программы могут вам помочь для анализа процесса hotfix.exe на вашем компьютере: Security Task Manager отображает все запущенные задания Windows, включая встроенные скрытые процессы, такие как мониторинг клавиатуры и браузера или записей автозагрузки. Уникальная оценка рисков безопасности указывает на вероятность процесса быть потенциально опасным — шпионской программой, вирусом или трояном. Malwarebytes Anti-Malware определяет и удаляет бездействующие программы-шпионы, рекламное ПО, трояны, кейлоггеры, вредоносные программы и трекеры с вашего жесткого диска.
hotfix сканер
Security Task Manager показывает все запущенные сервисы Windows, включая внедренные скрытые приложения (например, мониторинг клавиатуры или браузера, авто вход). Уникальный рейтинг надежности указывает на вероятность того, что процесс потенциально может быть вредоносной программой-шпионом, кейлоггером или трояном.
Бесплатный aнтивирус находит и удаляет неактивные программы-шпионы, рекламу, трояны, кейлоггеры, вредоносные и следящие программы с вашего жесткого диска. Идеальное дополнение к Security Task Manager.
SpeedUpMyPC бесплатное сканирование, очистка, восстановление и оптимизация вашей системы.
Многие пользователи компьютеров, работающих под управлением Windows, слышали о таком понятии, как «хотфикс». Что это такое и для чего это нужно, представляет себе далеко не каждый юзер. Однако ничего сложного ни в понимании этого термина, ни в предназначении таких инструментов нет. Далее, как говорится, разложим все по полочкам.
Хотфикс: что это такое?
Для понимания этого термина достаточно просто перевести его английское название. В Windows Hotfix дословно означает «горячее исправление». Иными словами, это есть инструмент быстрого устранения проблем с каким-то отдельно взятым компонентом Windows, если он не работает или функционирует некорректно.
Ситуация, с точки зрения многих пользователей, мягко говоря, забавная. Получается, что разработчики Microsoft выпускают какой-то программный продукт, который гипотетически может давать сбои, а потом начинают быстренько латать в нем дыры, используя для каждого из них хотфикс. Что это? Небрежность при разработке или умышленное действие, приводимое к тому, что пользователя просто заставляют скачивать средства устранения проблем? Думается все-таки второе, поскольку трудно допустить, что в такой уважаемой корпорации работают специалисты, которые не тестируют свои программные продукты на возможное появление ошибок.
Условия установки исправлений
Что же касается установки быстрых исправлений, здесь есть свои подводные камни. Кроме того, что их можно загрузить исключительно с официального сайта Microsoft, сначала необходимо дать запрос, причем по конкретно интересующему пользователя приложению или системному компоненту.
Впрочем, трудностей здесь быть не должно, поскольку прямо на сайте в разделе поддержки нужно выбрать требуемое исправление, указать свою установленную операционную систему и ввести адрес электронной почты. В течение определенного времени придет ответ со ссылкой на загрузку и паролем к архиву (все хотфиксы поставляются исключительно в упакованном виде).
Как установить хотфикс: практические действия
После загрузки архива его необходимо распаковать в любое удобное место, введя для доступа присланный пароль. После разархивирования на жестком диске появится исполняемый файл с номером исправления (так называемый изолированный пакет «Центра обновления»).
Далее все просто. Запускаете файл (желательно сразу использовать старт от имени администратора), соглашаетесь на инсталляцию обновления, дожидаетесь окончания процесса и полностью перегружаете компьютерную систему. По идее, после интеграции обновления приложения или системные компоненты заработают как положено.
Сразу же обратите внимание, что скачивать подобные инструменты с ресурсов, не относящихся к службам поддержки Microsoft, крайне не рекомендуется. И это связано в основном только с тем, что сами архивы или, вложенные в них, апплеты могут содержать вирусные коды, не говоря о том, что вместо хотфикса вам могут подсунуть какое-то другое нежелательное программное обеспечение. Поэтому обращаться следует только к официальному ресурсу.
А проще всего воспользоваться программой Hotfix Downloader, выбрать из списка нужное обновление для своей версии ОС, скачать его и инсталлировать. Так не придется искать хофиксы вручную.
Вместо послесловия
Вот и все, что касается такого понятия, как «хотфикс». Что это такое, думается, уже понятно. Некоторые пользователи, правда, относят сюда еще и утилиты вроде FixIt. В известном смысле эта программа тоже является хотфиксом, правда, изначально предназначена для устранения проблем, связанных исключительно с «Центром обновления» Windows. Для восстановления работоспособности других встроенных приложений и системных служб она не подходит хотя в их неработоспособности «Центр обновления» и может быть виновен, но только косвенно. Впрочем, иногда проблемы могут быть устранены за счет включения автоматического обновления. В таком случае использование хотфиксов может и не потребоваться.
Запла́тка, или патч (англ. patch /pætʃ/ — заплатка) — информация, предназначенная для автоматизированного внесения определённых изменений в компьютерные файлы. Применение патча иногда называется «пропатчиванием».
Патчем или обновлением англ. update называется, в частности, содержащее такую информацию автоматизированное отдельно поставляемое программное средство, используемое для устранения проблем в программном обеспечении или изменения его функциональности.
Исправление может применяться к уже установленной программе, либо к её исходным кодам. Сюда входит исправление ошибок, изменение внешнего вида, улучшение эргономичности или производительности программ, а также любые другие изменения, которые разработчик пожелал сделать.
Размер патчей может варьироваться от нескольких килобайт до сотен мегабайт. В частности, очень большими патчи могут быть при изменении или замене непрограммных данных, таких как файлы с графикой и звуком (часто встречаются в компьютерных играх). Тем не менее, большой размер может быть вызван и многочисленностью вносимых изменений. При этом слова «патч», «заплатка» обычно используются для обозначения небольших исправлений, большие же патчи, серьёзно меняющие или обновляющие программу, часто называются «service pack» или «software updates».
Содержание
Причины использования патчей
История
Позже для распространения патчей стали использоваться магнитные ленты. Когда же были изобретены дискеты, патчи стали отправляться на дискетах в конвертах по почте. Сегодня, в эру повсеместного распространения интернета, компьютерные программы и их пользователи скачивают патчи с сайтов разработчиков.
Виды патчей
Применение
Коротко выполняемые патчами задачи можно описать следующими действиями:
Программное обеспечение
Для автоматического обновления у конечного пользователя патчи используются обычно в крупных проектах, где важен объём пересылаемых данных.
При разработке программного обеспечения и т. п. патчи к исходным текстам используются независимо от размера проекта, обычно с помощью систем управления версиями. Созданные патчи, исправляющие частные проблемы или добавляющие некоторую функциональность, такую как поддержка других языков, обычно отправляются авторам или публикуются в сети.
Например, при разработке ядра операционной системы Linux, Линус Торвальдс, его автор, получал тысячи писем с патчами к его версии от множества программистов.
Веб-сервер Apache развился из набора патчей, написанных ранее различными веб-мастерами для добавления функциональности к NCSA HTTPd. По легенде, отсюда и возникло название — означающее, что это есть по сути коллекция патчей: «a patchy server».
Музыкальное ПО
В программах для создания музыки патчем называется сохранённый в памяти музыкального синтезатора набор программируемых параметров звучания определённого звука. Программный модуль, содержащий различные дополнительные звуковые эффекты и пресеты.
Участие пользователя в обновлении ПО
Бывает, что само обновление становится причиной новых ошибок в работе. Поэтому опытные пользователи предпочитают выждать некоторое время, пока не появятся первые отзывы о результатах использования новой версии ПО, и уже потом решают, стоит ли устанавливать данный патч. Особенно критичен данный момент для системных администраторов и при установке больших обновлений операционной системы.
Принудительное обновление
Иногда разработчики программ принуждают пользователей к обновлению. Это может выражаться в ограничении доступа с помощью необновлённой программы к сервисам разработчика (например, невозможности устанавливать последующие патчи и обновления), либо в полном или частичном отказе самой программы.
Причинами могут быть:
Патч встроенного ПО
Во многих устройствах программное обеспечение находится в памяти самого устройства в виде т. н. прошивки, которая включает в себя сразу и операционную систему, управляющую работой устройства, и собственно набор программ, обеспечивающих выполнение тех или иных его функций. Поэтому если разработчиком предусмотрена возможность замены его прошивки (перепрошивка), то применение патча на программное обеспечение устройства чаще всего представляет собой полную замену целиком всей прошивки на более новую версию. Обычно такой патч состоит из файла, содержащего обновленный программный код в двоичном виде, и специальной программы, записывающей его в память устройства вместо прежней версии. Пример такого вида патчей — перепрошивка БИОСа материнской платы компьютера или современного мобильного телефона, подключённого к компьютеру.
Поскольку по сути перезаписывается не какая-то часть программ или функций, а вся операционная система устройства, любая неожиданная ошибка или вмешательство в процесс перепрошивки (например, выключение питания) могут помешать корректно записать её до конца, что в свою очередь чаще всего приводит к полной неработоспособности устройства.
Разработка патчей
Для создания, использования и учёта патчей используют системы управления версиями.
Автоматизация установки
Зачастую современные программы обновлений могут управлять патчами. Автоматизация всего процесса упрощает задачу конечного пользователя — ему достаточно запустить программу, а та уже решит, нужно ли ставить патчи, и в каком порядке. Бывает и так, что программа скачивает обновления из интернета без участия пользователя. Такой способ часто применяется в поддержке серверного программного обеспечения и операционных систем. В ситуации, когда администратору приходится следить за несколькими компьютерами такой подход помогает поддерживать надёжность системы в целом. Обычно таким способом происходит установка обновлений безопасности.
Вспомогательные утилиты
Чтобы все изменения, совершаемые патчем, происходили автоматически без участия пользователя, существуют специальные утилиты, с помощью которых создают самоустанавливающиеся патчи. В них записывается информация, какие файлы должны быть заменены, или какие программы запущены после распаковки, если должно быть изменено содержимое файлов. Чаще всего полученный таким образом патч представляет собой самораспаковывающийся архив, содержащий обновленные файлы целиком.