Инструмент для построения Low-code DevOps практик

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

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

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

Обычная разработка

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

Непрерывная разработка и доставка продукта (DevOps)

Непрерывная разработка и доставка продукта (DevOps)

Данный цикл отражает основные этапы, заложенные в культуру непрерывной доставки продукта до потребителя. Если говорить про задачу переноса решения между несколькими окружениями, то она затрагивает два этапа - Непрерывная интеграция и Выкладка (в английской литературе их коротко называют CI / CD).

Непрерывная интеграция (Continuous integration) - это практика частой интеграции нового или измененного кода с существующим репозиторием кода. Если говорить проще, то это необходимость в команде из нескольких человек сливать изменения каждого в общий репозиторий как можно чаще, для поиска ошибок или синхронизации разработок.

Непрерывная сборка и выкладка (Continuous delivery and deploy) - это подход к разработке программного обеспечения, при котором программное обеспечение производится короткими итерациями, гарантируя, что ПО является стабильным и может быть передано в эксплуатацию в любое время. При этом процесс выкладки продукта полностью автоматизирован.

При реализации этого подхода в разработке ПО очень часто встает еще один вопрос - хранение и версионирование исходного кода решения (мы не будем останавливаться на разборе существующих решений).

Утилита elma365pm

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

Жизненный цикл продукта

В качестве инфраструктуры хранения исходного кода и непрерывной сборки организация использует сервер GitLab (для примера выбран наиболее популярный продукт с возможностью развернуть свой сервер в закрытом контуре).

Разработчик low-code решения выполняет работу на окружении Разработки. Это может быть один общий стенд для всех разработчиков или у каждого может быть поднят свой стенд. Разработчик работает с решением “Закупки” (procurement_solution), которое состоит из раздела с несколькими приложениями и модуля, в котором реализованы действия и виджеты интеграции с внешней системой.

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

elma365pm export solution --token=TOKEN --host=https://dev15-elma365.myorg 
--out=procurement --code=procurement

Токен для экспорта и импорта мы берем из Администрирование - Токены, под пользователем с правами администратора.

После выполнения этой команды в папке /procurement будут лежать файлы данного решения. Далее разработчик использует инструменты работы с репозиторием git, фиксирует свои изменения (commit) в отдельную рабочую ветку (branch) и отправляет их в общий репозиторий (push) на сервер GitLab.

Далее разработчик, согласно внутреннего регламента, создает на сервере GitLab запрос на слияние в рабочем репозитории решения из своей ветки в общую ветку develop. В этом запросе можно увидеть пофайлово и построчно различия между текущей общей версией решения и кодом решения от разработчика.

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

Сборка артефакта решения .e365 (для использования в целях тестирования):

elma365pm pack --src=procurement --out=dist/procurement.e365

Выкладка решения на общий тестовый стенд:

elma365pm import --token=TEST-TOKEN --host=https://test-elma365.myorg 
--src=procurement --version-up --force

В данном случае мы выкладываем на тестовый стенд, поэтому принудительно проглатываем ошибки флагом --force.

Финальной стадией является выкладка решения на окружение Продуктива. Для этого ответственный за выкладку вешает новый тег на конкретный коммит в репозитории решения и автоматически запускается выкладка решения.

elma365pm import --token=PRODUCTION-TOKEN --host=https://elma365.myorg 
--src=procurement --version-up

При выкладке на продуктив команда будет падать на любом конфликте.

К этому моменту уже понятно, что использование утилиты elma365pm значительно упрощает построение процессов сборки и выкладки решений. С её помощью можно построить процессы разработки и выкладки различной сложности. Мы описали наиболее классический подход, однако в каждой организации эти процессы имеют свой собственный оттенок.

Вместе с этим, самая важная новинка - это возможность работать с решением low-code как с набором файлов. Благодаря этому и команде сборки / выкладки можно гибко управлять переменными окружения, секретами или даже собирать из одних и тех же исходников разные продукты.

Как начать пользоваться?

Для начала вы можете уже сейчас скачать последнюю версию для вашей платформы (поддерживается linux, mac, windows). Она уже совместима с нашим облаком и с версиями ELMA365 On-premises 2022.4 и выше.

Получить справку о доступных командах можно прямо в командной строке:

elma365pm --help

Сама утилита имеет независимый цикл разработки и будет выпускаться отдельно от основной платформы. Нужно помнить, что последняя версия утилиты всегда будет совместима с нашим облаком, однако совместимость с более старыми версиями On-premises не гарантируется, для этого вам всегда будет доступна возможность скачать архивную версию утилиты.