Команда разработчиков холдинга столкнулась с ограничениями платформы ELMA 365 при попытке внедрить стандартные практики CI/CD и работы с кодом в репозитории. Хотя платформа позиционируется как low-code решение, скрипты виджетов на TypeScript требуют ревью, контроля версий и возможности отката изменений, чего не обеспечивает встроенный редактор внутри веб-дизайнера. Официальная утилита для экспорта и импорта решений работает нестабильно при изменении кода виджетов, выдавая ошибки при попытке загрузки обратно. Это вынудило команду создать собственный конвейер, чтобы перенести разработку из браузера в файловую систему и систему контроля версий.
Для реализации этого процесса разработчики сначала использовали хрупкий автоматизированный бот, который эмулировал действия человека в веб-интерфейсе: логинился, вставлял код в редактор и публиковал изменения. Этот подход оказался ненадежным из-за особенностей работы интерфейса, таких как автоматическое закрытие скобок редактором и отсутствие доступа к полному исходному коду при проверке. Кроме того, обновление платформы сломало логику бота, так как кнопка «Опубликовать» стала активна даже при наличии ошибок компиляции. В результате команда пришла к выводу, что автоматизация через браузер допустима только как временное решение, если отсутствуют API или командная строка.
Далее исследователи обратились к серверной части платформы, чтобы понять механизм работы кнопки «Проверить». Оказалось, что платформа отправляет задачу в очередь RabbitMQ, где рабочий сервис на Node.js использует стандартный компилятор TypeScript. Ключевым моментом стало то, что сервер генерирует файл описания типов для каждого виджета, включающий контекст формы, поля приложения и серверные функции. Команда смогла воспроизвести этот процесс локально, используя тот же компилятор и запросы, что и сервер, и повторила логику обертки кода и транспиляции. Сравнение результатов локальной компиляции и серверной проверки для 74 виджетов модуля договоров показало полное совпадение байт в байт, что подтвердило возможность использования локального компилятора для валидации кода.
В процессе внедрения были выявлены критические нюансы импорта решений. Во-первых, сервер при импорте не перекомпилирует скрипты, а использует скомпилированный код из пакета, что может привести к расхождению между исходным текстом и работающим кодом. Во-вторых, сервер-автор решения не принимает новую версию собственного виджета из файла, если она вычисляется по тому же идентификатору, что и существующая версия, в то время как на серверах-установщиках импорт проходит успешно. Также обнаружилась ловушка «тихого успеха»: если версия объекта в пакете совпадает с серверной, импорт пропускает изменения без применения, выдавая успешный статус. Для предотвращения таких ситуаций в конвейер были добавлены обязательные этапы повторного экспорта после установки и локальной проверки соответствия скомпилированного кода исходникам.
Финальная архитектура конвейера включает выгрузку решения, правку исходников в репозитории, локальную компиляцию с проверкой типов и сравнение с серверным результатом, установку на тестовый стенд, повторную выгрузку для сравнения с отправленным пакетом и коммит только тех изменений, которые реально записались на сервер. Перед установкой обновлений от внешних поставщиков также проводится сравнение живых форм с входящим пакетом, так как обновление может содержать полную пересборку форм, в которой будут потеряны локальные доработки. Этот подход позволяет интегрировать разработку на ELMA 365 в стандартный цикл разработки, обеспечивая контроль качества и стабильность изменений.
