Low-code — это тоже разработка. Как мы перестали настраивать систему мышкой и начали ею управлять

Почему компании стоит относиться к конфигурации ELMA 365 как к коду: контроль, повторяемость и меньше сюрпризов в продакшне

Low-code продают как способ обойтись без программистов. Нарисовал форму, настроил процесс, опубликовал. Первые месяцы это правда.

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

Я руковожу направлением бизнес-приложений в холдинге. Мы строим на ELMA 365 модули для договоров, контрагентов, корреспонденции, доверенностей и облигаций. За последние недели мы перевели разработку этих модулей с «кликаем в браузере» на нормальный конвейер с репозиторием. Расскажу, зачем это бизнесу и что мы нашли по дороге.

В типичном low-code проекте вся логика живёт внутри работающей системы. Формы, поля, права, процессы и скрипты настраиваются в веб-дизайнере. Это удобно для одного человека и опасно для команды.

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

Для руководителя это риск, а не техническая деталь. Сломанный процесс согласования договоров стоит денег. Потерянная доработка стоит времени и доверия к ИТ.

У ELMA 365 есть утилита, которая выгружает решение в файлы. Выгрузка работает хорошо: формы, процессы, права и скрипты превращаются в набор файлов, которые можно хранить в git.

Загрузка обратно работала для форм и подписей. Но не для скриптов виджетов. Официальная позиция вендора простая: такой код пишется в браузерном дизайнере, другого документированного пути нет.

Можно было принять это как данность. Мы решили сначала понять, что происходит за кнопками «Проверить» и «Опубликовать».

За кнопкой оказался обычный компилятор TypeScript, который запускается на сервере через очередь задач. Для каждого виджета сервер готовит описание типов: какие поля есть у формы и у приложения. Компилятор проверяет код и, если всё в порядке, собирает его.

Раз компилятор обычный, его можно повторить. Мы запустили его у себя с теми же версиями и настройками. А потом доказали, что результат совпадает: прогнали все 74 виджета модуля договоров через свой компилятор и через серверный. Результат побайтно одинаковый.

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

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

Успех может быть ложным. Если в пакете не отмечена новая версия объекта, загрузка молча пропускает его и рапортует об успехе. А скомпилированный код сервер берёт из пакета как есть, не пересобирая. Значит, текст и работающий код могут разойтись незаметно. Поэтому после каждой установки мы выгружаем решение обратно и сравниваем. И держим автоматическую проверку, что исполняемый код соответствует исходнику.

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

Изменение проходит один и тот же путь. Выгружаем текущее состояние. Правим код в репозитории. Компилируем локально против типов нужного сервера. Смотрим дифф. Ставим на тестовый сервер. Выгружаем снова и сверяем с тем, что отправляли. Только после этого изменение считается сделанным.

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

Для переноса появился простой реестр. На каждое готовое изменение — карточка: что меняется, как проверить на тесте, как убедиться в продакшне. Статусы: «Ожидает переноса», «На Test», «На PROD». Скучно? Очень. Зато ни одна доработка больше не лежит забытой две недели.

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

Отсюда правило, которое я теперь предлагаю всем: автоматизировать интерфейс только там, где нет командной строки или API. Робот в браузере — запасной путь, а не основа процесса.

Контроль. Любое изменение видно в истории: кто, что, когда и зачем.

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

Меньше риска. Мы проверяем не «команда завершилась», а фактическое состояние сервера. Ложные успехи ловятся до того, как их заметят пользователи.

И ещё одно. ИИ-агенты становятся полезными. Агенту нужен файл, а не браузер. Как только код живёт в репозитории, агент может писать его, а человек — проверять дифф. Без этого шага ИИ в low-code остаётся игрушкой.

Low-code экономит время на старте. Но если компания строит на нём важные процессы, ей нужна та же дисциплина, что и в обычной разработке: репозиторий, ревью, проверяемая установка. Платформа не обязана давать это из коробки. Это можно построить самим.