Как я переустановил Windows с помощью одного YAML-файла через winget

Настройка нового компьютера или чистая установка операционной системы часто отнимает много времени на поиск и скачивание привычного софта. Чтобы избавиться от рутинного клика по установщикам, можно использовать официальный пакетный менеджер Microsoft и создать единый сценарий автоматизации. Подробно о том, как устроен этот подход, рассказано в официальной статье на сайте XDA Developers.

Инструмент winget позволяет автоматизировать развертывание программ и базовых параметров системы. В этом обзоре мы рассмотрим практический опыт автоматизации установки ПО с помощью конфигурационных файлов.

Экспорт установленного софта и ограничения команды

Утилита winget представляет собой официальный менеджер пакетов командной строки от Microsoft, функционал которого во многом напоминает пакетные менеджеры в Linux. С его помощью можно искать, устанавливать, удалять и обновлять приложения. Особое значение для автоматизации имеет команда экспорта, позволяющая выгрузить список всех инсталлированных пакетов в файл формата JSON.

При выполнении команды экспорта с фиксацией версий создается перечень программ, найденных в репозиториях winget и Microsoft Store. Однако такой файл не охватывает софт, установленный вручную из независимых источников. Кроме того, полученный JSON-документ не подходит напрямую для команды настройки, которой требуется формат YAML. Из-за этого файл приходится предварительно конвертировать и редактировать вручную, удаляя дубликаты, возникшие из-за параллельного наличия системных и пользовательских версий приложений.

Подготовка конфигурационного файла YAML

Для применения параметров используется команда настройки winget, способная за один проход обрабатывать как приложения, так и конфигурацию операционной системы. Поскольку команда экспорта не переносит настройки Windows, их требуется добавлять в итоговый YAML-документ вручную. В число таких параметров могут входить включение режима разработчика, отображение скрытых файлов и расширений, а также активация темной темы оформления.

При работе с большим количеством программ целесообразно разделить общий перечень на несколько логических частей. Например, выделить в отдельный файл основные инструменты разработчика и повседневный софт, а во второй документ — вендорские утилиты, игровые лаунчеры и специализированные приложения. Подобное разделение упрощает тестирование и дальнейшее обслуживание конфигурации.

Тестирование конфигурации на виртуальной машине

Перед применением файла на рабочем ПК работоспособность сценария проверяется на изолированной виртуальной машине. В тестовом окружении с чистой установкой Windows 11 проверяется наличие актуальной версии пакетного менеджера. Перед запуском конфигурации требуется включить саму службу настройки с помощью специальной команды активации, после чего выполнить валидацию файла.

В ходе тестовых испытаний с набором из нескольких десятков приложений и заданными параметрами системы процесс установки занимает около 12–14 минут при условии своевременного подтверждения системных запросов. Подобные тесты подтверждают жизнеспособность выбранного метода, хотя и выявляют некоторые технические нюансы, связанные с правами администратора и всплывающими окнами контроля учетных записей.

Что остается за рамками автоматизации

Важно учитывать разницу между установкой программ и их полноценной конфигурацией. Пакетный менеджер успешно скачивает и инсталлирует приложения, однако они открываются в состоянии «по умолчанию»: в браузерах отсутствуют истории и профили, утилиты требуют повторного входа в учетные записи, а специализированные среды разработки не содержат ранее установленных плагинов, если те не были прописаны в сценарии явно.

Кроме того, конфигурационные файлы не фиксируют версии жестко намертво, поэтому система может получить более свежие сборки ПО. Лицензионные пакеты вроде офисных или графических суитсов требуют отдельной авторизации и ввода ключей вручную. Также в целях безопасности из подобных скриптов осознанно исключаются конфиденциальные данные, такие как SSH-ключи и учетные данные Git.

Создание надежной базы вместо точной копии

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

Документируемый и повторяемый базовый сценарий оказывается значительно эффективнее ручной установки с нуля или попыток вспомнить весь необходимый софт по памяти. Это удобный подход для быстрой подготовки рабочего места после переустановки операционной системы.