Как я сделал инструмент, о котором мечтал много лет

Загрузка конфигурации 1С из git в базу за секунды, без открытия Конфигуратора. Одно окно вместо десятка командных строк: частичная загрузка по коммитам, выгрузка, объединение, проверка конфигурации, YAxUnit, конвертация EDT и режим MCP-сервера для ИИ-агента. Python, стандартная библиотека, один exe.

Вкладка «Загрузка»

Откуда взялась мечта

Четыре года я работал в компании-интеграторе. Там я узнал, что такое git и EDT, и научился с ними работать. Git мне понравился сразу и навсегда. После хранилища конфигурации это другой мир: за секунды видно, кто и что менял, в каком коммите, по какой задаче. В хранилище за таким ответом идёшь через историю объектов и сравнение версий, и то не всегда доходишь.

Но путь был тернистым. Работа в EDT оставляет желать лучшего: среда тормозит, а при обновлении базы возникают ошибки, особенно если это ERP. Нужна мощная машина, и даже на ней большая конфигурация собирается от 20 минут и больше. Спасением стало то, что EDT начал использовать автономный сервер ibcmd вместо Конфигуратора для обновления базы. Стало заметно лучше, но всё равно не гладко: автономник в EDT работает только с файловой базой, а разработка под ERP на файловой базе это отдельное удовольствие.

Постепенно созрело желание отказаться от EDT совсем и работать так: git плюс обычный Конфигуратор. Конфигуратор не тормозит, не требует 32 ГБ памяти, и в нём привычно. Проблема была ровно одна. Если загружать изменения из файлов руками, Конфигуратор делает это очень долго: он читает всё дерево метаданных, даже когда поменялись три модуля. Открыть Конфигуратор, дождаться, выбрать «Загрузить конфигурацию из файлов», посмотреть на прогресс-бар 10–20 минут, потом «Обновить конфигурацию базы данных». На большой типовой конфигурации цикл легко съедает полчаса, и так на каждый чужой коммит.

При этом git точно знает, какие файлы поменялись между двумя коммитами. Мечта звучала просто: выбрал коммит, нажал кнопку, через минуту изменения в базе. Без ручных списков файлов, без ожидания.

Долгое время это было невозможно технически. Загрузка из файлов умела только весь каталог целиком либо список через -listFile, который надо было собирать самому и который на кириллице вёл себя непредсказуемо. Потом автономный сервер ibcmd получил команду config import, а в 8.3.27 у него появился режим config import files --partial, который грузит только перечисленные файлы. Пазл сложился: тот самый автономник, который спасал EDT, теперь можно было использовать без EDT, напрямую из git. Оставалось написать инструмент, который их соединит. Но мечта так и лежала бы мечтой, если бы не два события.

Точка кипения

Я устроился на новую работу. Команда как раз хотела перейти на git, а тут я со своим огромным опытом. Я сказал: хорошо, сделаем. Развернул свежую версию EDT, загрузил XML в репозиторий, создал расширение и начал грузить его в проект. И EDT руинит мне проект. Файлы XML в полном порядке, но проект надо сбрасывать и снова ждать, пока рассчитается контекст. Полчаса, а то и час ожидания, и это на пустом месте.

В этот момент меня подкинуло. Я представил, как рассказываю команде, до чего хороши git и EDT, а на второй день у кого-то вот такое. Команда, как обычно, начнёт ныть, и будет права. Я сидел и думал: что я могу сделать для них, чтобы git они полюбили, а EDT им не пришлось терпеть.

Про ИИ

Вторая деталь. На прошлой работе нам запрещали использовать ИИ. На новой ситуация обратная. А тема ИИ мне очень по душе: я много читаю и смотрю про это, практикую дома, и теперь наконец мог практиковать на работе.

Тут надо признаться в одной вещи. За годы в 1С у меня осталась сплошная рутина. Я давно не ощущал того чувства, что я творец и могу сделать что захочу. Оно угасло, и я даже не заметил когда. А с ИИ это чувство вернулось: возможности показались безграничными. Хочу инструмент, которого нет, значит, будет.

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

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

Дальше пошёл цикл. Агент реализовывал ТЗ, я проверял на живой базе, находил грабли, и они возвращались в ТЗ как правила. Так появилась половина того, что описано ниже. Например, файловая база при каждой загрузке с реструктуризацией разрасталась, и её нужно было сжимать, иначе она упиралась в предел размера. Отсюда взялись галочки «сжать перед загрузкой, если база больше 6 ГБ» и «сжать после», а потом и целая вкладка обслуживания. Ни того, ни другого в первом ТЗ не было.

Приложение занимало меня всё время. Даже в электричке по дороге домой приходили идеи: а если фильтровать отчёт проверки конфигурации по коммиту, а если брать список баз из окна запуска 1С. Я записывал, дома превращал в ТЗ, на работе проверял. На каждую вкладку в итоге получилось своё ТЗ, они до сих пор лежат в репозитории рядом с кодом. Всё, что в этой статье называется «выяснилось экспериментом», выяснилось именно так: я нажимал кнопку, читал лог, а потом описывал, как должно быть.

Так появилось приложение, которое у меня внутри называется просто «021».

Что получилось

Окно на Tkinter с десятью вкладками. Внизу статус-бар с таймером и кнопкой «Стоп», которая честно убивает дерево процессов ibcmd или 1cv8 и прерывает цепочку шагов. Никаких зависимостей кроме Python, собирается PyInstaller в один exe.

Общие настройки

Архитектура намеренно простая. Окно и MCP-сервер, о котором ниже, это два тонких входа в одно ядро операций. Ядро собирает командные строки, запускает внешние процессы, гонит их вывод в лог и не знает ничего про виджеты. Это позволило покрыть ядро тестами и переиспользовать его без окна.

Архитектура приложения

Главное: частичная загрузка по коммитам

Это ради чего всё затевалось. На вкладке «Загрузка» указываю каталог с XML-выгрузкой (он же git-репозиторий) и выбираю, что грузить:

• диапазон коммитов «от..до»: «от» это базовая точка в прошлом, сам коммит не грузится, берутся изменения после него; пустое «до» означает HEAD;
• изменения одного коммита: выбираю коммит X, приложение само берёт X~1..X.

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

Схема частичной загрузки

По дороге накопился набор правил, каждое из которых оплачено конкретной шишкой:

Кириллица в путях. Первый вариант передавал список файлов через stdin. На кириллических именах объектов ibcmd отвечал «Неизвестный объект метаданных»: список он читает в системной ANSI, а UTF-8 ломает имена. Теперь пути идут позиционными аргументами через CreateProcessW, то есть в Unicode, а при большом числе файлов команда сама режется на пакеты в пределах лимита длины командной строки Windows.

Configuration.xml в диапазоне. Если изменился состав конфигурации (добавили или удалили объект), частичная загрузка корня всё равно заставляет ibcmd перечитать всё дерево, по времени это как полная, но без её гарантий целостности. Поэтому приложение в этом случае само переключается на полную загрузку и пишет об этом в лог.

Удаления. Частичная загрузка не удаляет объекты. Удалённые и переименованные файлы показываются предупреждением, их надо закрывать полной загрузкой.

Несколько выгрузок в одном репозитории. Если рядом с config/ лежат ext/Расширение1/ и test/, изменения фильтруются по выбранному каталогу XML. Отфильтрованное видно в логе отдельным списком «Вне каталога XML».

Порядок шагов. Сжатие таблиц перед загрузкой (если файловая база больше 6 ГБ), затем config import, затем выгрузка .cf, затем config apply, затем сжатие после. Выгрузка .cf идёт до apply намеренно: если реструктуризация пробьёт предел размера файловой базы, .cf уже сохранён.

Так выглядит лог реальной загрузки одного изменённого модуля менеджера в файловую базу на 4,7 ГБ. Сама загрузка заняла 8 секунд, обновление конфигурации базы данных 21 секунду, ещё 48 секунд ушло на сжатие таблиц после. Итого полторы минуты вместо получаса. Ниже в том же логе виден прогон 56 тестов YAxUnit с загрузкой расширения, тоже полторы минуты:

Лог частичной загрузки и прогона тестов

Два метода: ibcmd и пакетный Конфигуратор

У ibcmd есть неприятная особенность с серверными базами: он подключается напрямую к СУБД, минуя кластер серверов 1С. Документация прямо предупреждает, что одновременная работа ibcmd и кластера с одной базой может её разрушить. Значит, перед загрузкой базу надо вывести из кластера, а это не всегда удобно и не всегда позволено.

Поэтому в приложении появился второй метод, «Пакетный режим Конфигуратора». Все те же операции выполняются через 1cv8 DESIGNER с ключами /LoadConfigFromFiles, /DumpConfigToFiles, /DumpCfg, /UpdateDBCfg. Медленнее, зато к серверной базе Конфигуратор ходит через кластер, и достаточно завершить сеансы.

Два метода работы с базой

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

Из мелочей, которые пришлось выяснить экспериментом: у пакетного метода при частичной загрузке нужно явно передавать -Format, и его значение приложение читает из атрибута format файла ConfigDumpInfo.xml, а не предполагает. Файл списка -listFile должен быть в UTF-8 с BOM, тогда кириллица читается правильно. А два ключа со словом force (apply --force и -SessionTerminate force) отвечают на разные вопросы, и приложение показывает их как две независимые галочки с разными подписями.

Ещё один замер, который меня удивил: загрузка из ZIP-архива не быстрее загрузки из каталога. На выгрузке 694 МБ пакетный метод показал 117 против 116 секунд, ibcmd 21 против 17, а создание архива стоит около минуты. Архив имеет смысл как способ перенести выгрузку одним файлом, а не как ускорение.

Выгрузка и защита .git

Обратная операция, выгрузка конфигурации базы в XML, оказалась опаснее, чем кажется. Полная выгрузка config export очищает каталог. Если выгружать прямо в git-репозиторий, первый же запуск сносит .git.

Вкладка «Выгрузка»

Приложение перед выгрузкой отодвигает .git, .gitignore и .gitattributes во временный резерв рядом с каталогом мгновенным переименованием, без копирования, и возвращает их после, в том числе при ошибке. Если .git занят другим процессом (открыт git-клиент, антивирус индексирует), перенос не выполнится, и приложение не станет запускать выгрузку. Резерв от прерванного запуска разбирается при следующем старте. Если в каталоге уже есть ConfigDumpInfo.xml, выгрузка идёт инкрементально.

После выгрузки можно сразу сделать коммит. Есть галочка «Коммитить без проверок (--no-verify)» для первой массовой выгрузки и обновлений типовой, когда хук pre-commit мешает, и подпись под ней просит держать её выключенной в остальное время.

Репозиторий одной кнопкой

Пока настраивал процесс для команды, надоело каждый раз руками писать .gitattributes, .gitignore и подключать хуки. Вкладка «Git-репозиторий» делает это одной кнопкой: структура папок config/, ext/, test/, epf_erf/, правильный .gitattributes с * -text (иначе git портит переводы строк в бинарных макетах), первый коммит, origin и хук precommit4onec, который при коммите разбирает внешние обработки в исходники и отклоняет коммит с буквой «ё» или смешением кириллицы и латиницы в идентификаторах.

Вкладка «Git-репозиторий»

Объединение по списку коммитов

Есть сценарий, когда частичная загрузка не подходит: изменения надо не заменить, а влить в конфигурацию, где параллельно поменялось что-то ещё. Например, донести доработку из ветки на релизный стенд. Для этого Конфигуратор умеет /MergeCfg с файлом настроек, но составлять файл настроек на 22 тысячи объектов руками никто не будет.

Вкладка «Объединение»

Вкладка «Объединение» строит этот файл сама: объекты, изменённые в диапазоне коммитов, берутся из .cf, все прочие получают правило DoNotMerge. Экспериментом выяснилось, что объекты, которых в файле настроек нет, 1С объединяет по умолчанию, поэтому файл перечисляет все объекты конфигурации. Для КА это около 22 600 записей и 3 МБ. Перед объединением можно посмотреть предпросмотр и открыть файл во внешнем редакторе.

EDT ; Конфигуратор

Форматы EDT и Конфигуратора несовместимы, а ibcmd понимает только формат Конфигуратора. Если часть команды осталась в EDT, нужна конвертация через 1cedtcli, и вкладка запускает её в обе стороны. Два наблюдения: указание готового workspace от EDT IDE пропускает самый тяжёлый этап, сборку модели, и на конфигурации из 7018 объектов даёт ускорение втрое (202 секунды против 62), а память JVM приходится задавать через переменную окружения _JAVA_OPTIONS, потому что -vmargs в командной строке launcher не принимает.

Вкладка «EDT; Конфигуратор»

Проверка конфигурации с фильтром по коммитам

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

Вкладка «Проверка конфигурации»

Выбираю коммит или диапазон, приложение переводит пути изменённых файлов в имена объектов метаданных (Documents/Х в Документ.Х) и оставляет в логе только сообщения по ним, остальное сворачивает в счётчик. Полный отчёт лежит рядом в файле. Фильтр ничего не загружает, проверяется конфигурация, уже находящаяся в базе. Ненулевой код возврата 1cv8 трактуется как «найдены ошибки», а не как сбой, и итог печатается вердиктом.

Unit tests и обслуживание базы

Вкладка «Unit tests» прогоняет YAxUnit: загружает расширение с тестами Конфигуратором, запускает 1cv8c ENTERPRISE /C"RunUnitTests=...", разбирает отчёт jUnit и показывает дерево «набор → тест». Упавшие тесты с сообщением и стеком, failure и error различимы.

Вкладка «Unit tests»

Одна деталь, на которую я потратил вечер: тесты отбираются по имени расширения в базе, а не по имени каталога. Несовпадение даёт «успешный» прогон с нулём тестов. Поэтому при нуле найденных тестов приложение выводит чек-лист, а код возврата берётся из файла exitCode, а не из кода процесса 1С.

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

Как это встроилось в процесс команды

Инструмент делался не сам по себе, а под регламент разработки через GitLab: ветки feature_*, merge request, ревью, двухнедельный релиз. В этом процессе 021 стоит на двух местах: у разработчика, чтобы за секунды подтянуть чужой коммит в свою базу и прогнать тесты, и у сборщика релиза, чтобы объединить изменения по списку коммитов на релизный стенд.

Цикл разработки

Режим MCP-сервера

Последнее, что добавил, и то, что ещё год назад не пришло бы в голову. Тот же exe, запущенный с ключом --mcp, не создаёт окна и работает как MCP-сервер по stdio. Claude Code или другой MCP-клиент получает операции приложения как инструменты: get_changes, load_config, export_config, check_config, run_unit_tests, check_infobase и другие.

{
  "mcpServers": {
    "1c-config-loader": {
      "type": "stdio",
      "command": "C:\\Tools\\021\\ibcmd-config-loader.exe",
      "args": ["--mcp"]
    }
  }
}

Теперь агент может сам загрузить свой коммит в тестовую базу, прогнать проверку конфигурации по изменённым объектам и юнит-тесты, прочитать результат и исправиться. Долгие операции возвращают job_id сразу, завершения ждут через wait_job. Одновременно выполняется одно задание, и оно же блокирует запуск операции из окна: файл operation.lock держат оба процесса.

Про безопасность думал отдельно. Пароли сервер берёт только из профиля, где они зашифрованы DPAPI под учётной записью Windows, параметрами инструментов они не передаются и в ответах не появляются. Разрушающие инструменты требуют явного confirm: true. И всё равно для агента разумно завести отдельного пользователя ИБ с правами только на тестовую базу.

Мелочи, которые решают

• Ctrl+C / Ctrl+V при русской раскладке. Tk сопоставляет копирование только с латинскими клавишами, а при русской раскладке вообще не распознаёт нажатие. Штатные сочетания молча не работали во всех полях. Приложение добавляет привязку по коду клавиши, который от раскладки не зависит.
• «Из списка баз...» читает ibases.v8i окна запуска 1С, с поиском по мере ввода. Двойной клик подставляет реквизиты и сам переключает режим файловая/серверная.
• Пароли не хранятся по умолчанию. Галочка включает хранение, зашифрованное DPAPI: профиль, скопированный на другую машину, пароли не отдаст.
• Тёмная тема с заголовком окна через DWM, DPI-awareness для мониторов 125–150%, геометрия окна запоминается с проверкой попадания на видимый экран.
• Кнопка «Стоп» завершает внешний процесс вместе с дочерними через taskkill /T и перед этим предупреждает, что прерванный apply может оставить конфигурацию базы в незавершённом состоянии.

Тёмная тема

Честно об ограничениях

• Частичная загрузка не удаляет объекты и работает только в базу, где уже есть совместимая конфигурация. Первый раз в пустую базу только полная.
• Изменение состава конфигурации (Configuration.xml в диапазоне) переключает на полную загрузку автоматически.
• Серверный режим ibcmd требует вывести базу из кластера. Если это невозможно, пакетный метод.
• Объединение работает только для основной конфигурации. Расширение маленькое и грузится целиком за секунды, выборочный merge ему не нужен.
• Запрет новых подключений (sessions-deny) ни ibcmd, ни пакетный Конфигуратор не умеют, это делает кластер через rac. Сценарий «запретить вход, выгнать, обновить, разрешить» пока не реализован.
• Нативные диалоги Windows тёмная тема не перекрашивает.

Цифры

Где взять

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

Вместо заключения

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

И второе, личное. Я снова почувствовал себя творцом. Не тем, кто закрывает задачи из очереди, а тем, кто видит проблему у команды и через пару недель приносит решение, которого раньше не было. ИИ здесь не заменил меня, он убрал стоимость попытки. Инструмент, о котором я мечтал годами, оказался вопросом решимости сесть и описать, как он должен работать.

Если вы годами делали то же самое руками, посмотрите на ibcmd config import files --partial. Возможно, ваша мечта тоже уже технически возможна, просто её пока никто не завернул в кнопку.

Буду рад вопросам и историям про ваши грабли с ibcmd и пакетным Конфигуратором в комментариях.