Привет Хабр!

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

Как мы к этому пришли?

Те, кто в последние годы сталкивался с Единым государственным экзаменом по информатике, могут знать, что с 2021 года он проводится в компьютерной форме: школьники выполняют различные задания на ПК. Работа с таблицами, языками программирования, текстовыми редакторами — всё это, конечно, хорошо, но это добавляет школам большое количество работы в рамках подготовки к экзаменам. Теперь недостаточно просто распечатать бланки, нужно ещё убедиться, что на компьютерах стоит все нужное ПО нужных версий. И вот тут-то и начинается веселье в виде установки десятка программ на пару сотен компьютеров. И делается это всё в подавляющем большинстве случаев вручную, хотя это можно было бы автоматизировать, чем я и занялся в своей школе, тем более, что на эту автоматизацию у сотрудников был явный запрос.

Мини-дисклеймер перед прочтением:

Да, существует множество способов эту задачу сделать, не изобретая свой велосипед, тем не менее, вместе с реальной практической задачей существовало ещё и желание сделать что-то свое, поэтому не судите строго :)

Чем мы располагаем?

Нам необходимо автоматически ставить программы на Windows, притом желательно, чтобы это происходило не по сети. Почему мы отвергаем сетевую установку? Большинство устройств у нас — ноутбуки, и качество WiFi оставляет желать лучшего. Да и придется все эти устройства как-то идентифицировать в сети + возможно ставить какие-то агенты на сами компьютеры — в общем получается очень много подготовительной работы. Гораздо проще будет ходить с парой флешек, копировать файлы и тыкать по exe'шнику для установки.

Какие готовые решения у нас уже есть? Внимательный читатель к этому моменту уже, скорее всего, просто кричит: «Ansible!» Да, это действительно хороший инструмент, и он даже поддерживает работу с Windows, но, как я уже отметил, сетевая установка нам не подходит.

Другой вариант — Ninite. Это простая программка для автоматической установки некоторого пакета ПО на ту машину, на которой она сама же и запущена. На первый взгляд, то, что надо. Еще и куча серьёзных компаний ее используют, на официальном сайте декларируются: Sony, NASA и другие. Но при ближайшем рассмотрении моментально становится понятен огромный минус — нельзя туда добавить свое ПО, которого еще там нет, например, не получится ставить с помощью нее всякие специфичные программы типа PascalABC или Кумир.

Есть PSAppDeployToolkit. Но он выглядит и используется примерно так же как и называется. Его будет тяжело сконфигурировать и запустить. Нам же нужно максимальное упрощение — «ткнул, и заработало». Не стоит забывать, что целевая аудитория — школьные учителя. У админа, скорее всего, не будет времени долго разбираться со сложным синтаксисом утилиты, а реальной установкой зачастую занимаются совершенно далекие от ИТ люди.

Наша последняя надежда — PDQ Deploy. Заходим на сайт и тут же уходим: стоит $1500 и не работает с РФ.

Выходит, что нет достаточно простого, но при этом гибкого решения. Поэтому будем писать свое. Как оно будет выглядеть? Далеко за концепцией ходить не будем и возьмём тот же Ansible. У нас будут плейбуки, которые будут выглядеть как-то так:

name: Install software 
tasks:
  - name: Install some program
    std.install:
        name: MyProgram
        publisher: MyPublisher
        version: "1.0.0"
        installer: myprog_installer.exe

Исполняемый файл будет просто выполнять плейбук, лежащий рядом с ним. EXE-файлы установщиков должны быть приложены к плейбуку, либо их можно скачать с помощью std.download — задачи на скачивание файла по URL.

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

Если б все было так хорошо...

Во-первых, Windows не имеет никакой стандартизации в этой сфере. И под словом «никакой» я подразумеваю вообще никакой. Некоторые, конечно, могут возразить, что есть msi, Microsoft Store, но будем честны — даже не треть ПО ставится через них. Это тщетные попытки сделать то, что надо было делать несколько десятилетий назад, еще при появлении NT. А сейчас мы имеем целый зоопарк инсталляторов и деинсталляторов: каждая программа ставится как хочет, и что делать с этим — непонятно.

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

Как оказывается, Панель управления берёт весь список из реестра, а конкретно из HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Uninstall для machine-wide установок, и из соответствующего места в HKEY_CURRENT_USER для per-user установок. И только мы хотим порадоваться, что мы можем хоть на что-то положиться, но все наши розовые мечты разбиваются о суровую реальность. CurrentVersion/Uninstall, конечно, можно использовать как достоверный источник о всех установках на устройстве, за исключением нескольких маленьких «но»:

• НО нет никаких гарантий, что программа при установке создаст там запись;

• НО единственным полем, на которое можно рассчитывать, является DisplayName — отображаемое имя программы. Publisher (издатель) может быть пустым (привет, PascalABC.NET). Version может содержать:

  1. реальную версию

  2. какую-то другую версию (Python 3.13.1, но Version=3.13.1150)

  3. быть вообще пустым (снова привет, PascalABC.NET)

  4. может вообще отсуствовать В последнем случае могут еще встречаться поля MajorVersion/MinorVersion. Но и тут никто ничего не гарантирует, потому что они могут называться и VersionMajor/VersionMinor;

• НО 32-битные программы почему-то подвергнуты сегрегации и располагаются по совсем другим путям.

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

Ладно, хорошо, с этим можно смириться. Придется, конечно, немного накостылить, поддержать разные схемы, но жить можно. Пока что.

Тихая установка

Во-вторых, следующая проблема — тихая инсталляция / деинсталляция. Если мы будем просто запускать инсталляторы / деинсталляторы, то никакой автоматизации не получится, так как все равно придется тыкать на кнопочки в диалогах. Можно, конечно, прикрутить что-то вроде pyautogui или pywinauto и тыкать на них автоматически, но это не то, чего нам бы хотелось. Хочется чего-то более красивого и лаконичного. И такое есть. Большинство установщиков поддерживают тихую установку, не требующую вообще никаких действий со стороны пользователя: запустил exe'шник с нужным флагом, и готово.

И тут опять мы сталкиваемся с той же проблемой — зоопарком инсталляторов. Каждый инсталлятор имеет свои флаги тихой установки, и это проблема. К счастью, ее за нас уже решили: USSF (Ultimate Silent Switch Finder) позволяет подбирать такие флаги ко всем самым популярным системам установки: MSI, InnoSetup, Nullsoft Install System, InstallShield и кучу всего еще. Путем нехитрого анализа кода утилиты понимаем как она работает и пишем свою реализацию. Поддерживать будем только первые три типа установщиков, если будет надо — расширим. Код максимально прост:

def _is_inno_setup(installer: str) -> bool:
    with open(installer, "rb") as installer_f:
        data = installer_f.read() 
        return b"Inno Setup" in data


def _is_nullsoft_installer(installer: str) -> bool:
    with open(installer, "rb") as installer_f:
        data = installer_f.read()
        return b"Nullsoft Install System" in data


def determine_quiet_install_command(installer: str) -> str | None:
    if installer.endswith(".msi"):
        return f"msiexec /I {installer}" /passive /norestart'
    if _is_inno_setup(installer):
        return f"{installer} /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /SP-"
    if _is_nullsoft_installer(installer):
        return f"{installer} /S"
    return None

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

Вот, кстати, еще один смешной момент.
Вы наверняка знаете, что на Windows по умолчанию используются пути с \, в отличие от Linux/Mac с /. Но на Windows можно использовать и обычный слеш: cd C:/Users/User/Documents отработает замечательно. Да и вообще, где угодно можно использовать /, PowerShell поймет все. Или нет? А вот и нет. MSIExec — утилита для установки msi файлов — просто отказывается работать с обычными слешами. То есть утилита, предназначавшаяся для универсальной установки не работает с универсальными слешами. И в этом вся Windows :)

Что в итоге получилось

Спустя десятки часов страданий получается конечный результат. Программку я решил назвать Embark (англ. «производить погрузку на корабль»).

Мы запускаем exe'шник, он ищет все похожие на плейбуки файлы в текущем расположении и предлагает запустить один из них.

Затем открывается окно логирования, где отображается весь процесс установки в стиле GitHub Actions.

Если вдруг что-то пойдет не так, то Embark предложит выбрать: прерывать или продолжать работу.

Естественно, есть не только GUI, но и CLI, а также несколько дополнительных команд для поиска установленного ПО на компьютере, чтобы было проще находить правильные параметры для плейбука (привет проблемам реестра, о которых мы говорили ранее).

Думаю, про стек, использованный в Embark тоже стоит что-то сказать. Все работает на Python 3.13.2. В качестве UI библиотеки используется customtkinter. PyQT/PySide тащить не хотел из-за веса, а customtkinter довольно легкий, красивый и простой. Парсинг конфигов происходит через связку PyYAML + Pydantic.

Организация тестирования

Продукт достаточно серьёзный, будет не очень круто, если он поломается во время использования. Поэтому необходимо обеспечить автоматическое тестирование, чтобы убедиться, что явных проблем у нас нет.

Тесты в основном E2E, так как, пожалуй, во всем проекте немного мест, которые стоило бы тестировать юнит-тестами. В рамках этих E2E тестов проверяются входящие в стандартную поставку типы задач (copy, cmd, install, download). Отдельно проверяется работа интерфейса через скриншотные тесты — запускается окно с тестовыми элементами и скриншот сверяется с эталоном.

Статический анализ тоже имеется: типы проверяются mypy в строгом режиме, чистота кода через Ruff и «самый строгий линтер» wemake-python-styleguide. Для сохранения архитектурных слоев используется import-linter. Он позволяет контролировать зависимости внутри пакета: например, вы можете запретить core компонентам зависеть от плагинов.

Конечно же, нужно настроить CI для автоматического тестирования всего, что попадает в master. Сначала приложение тестируется на наборе тестов с помощью pytest, а затем проходит финальное тестирование, когда приложение собирается в exe-файл и запускается на реальном плейбуке. Здесь проверяется во-первых то, что утилита не упала, а во-вторых, с помощью команды embark dev_query_install выполняется поиск по реестру для того, чтобы убедиться в том, что нужное ПО установилось. Если вдруг что-то отвалится, то пайплайн приложит полную информацию, в том числе и для скриншотных тестов: сделанные скриншоты загрузятся как артефакты, чтобы можно было понять, что пошло не так.

И что в итоге?

В итоге получилось довольно простое и удобное приложение для автоматизации установки. Мы его внедрили в своей школе, которая как раз в этом году принимает экзамены. Этим самым мы существенно сократили дополнительную нагрузку на сотрудников школы, уменьшили время и увеличили качество подготовки. Если раньше приходилось на одну рабочую станцию тратить по 40 минут, еще и при этом постоянно тыкать там на кнопки, то теперь достаточно за пару минут скопировать плейбук и запустить Embark. Не всегда (в силу специфичности Windows и различных программ) оно работает гладко, конечно, но со своей основной задачей оно справляется, да и я постоянно фикшу баги.

Исходный код проекта, разумеется, на GitHub. Также доступна двуязычная документация.

Спасибо за прочтение!

Сталкивались ли вы с подобными проблемами? Как вам мой проект? Пишите свой опыт и мнение в комментариях!