Доставка решений. От ручных операций к DevOps инструментам построения CI/CD конвейера.

Текст выступления на конференции ELMA Day 2023 Алексея Пушкарёва


Термины

Решение – это некий набор программных компонентов, который решает какую-то бизнес-функцию.

Доставка – процесс, который происходит между разработкой этого решения и тем, как пользователи начинают им пользоваться. И главный вопрос, на который отвечает эта доставка: «Как наше решение сделать качественным, чтобы пользователи оставались довольными и не случалось проблем на пути от разработчика к пользователю?».

Зачем думать о процессах доставки и разработки решений в Low-code системе?

Как правило, вендоры говорят: «У нас low-code быстро сделали решение, и вот оно работает». Но на самом деле не всегда так получается. Поскольку происходит разработка, то неизбежны ошибки, появляющиеся в процессе. И желательно их не проверять на пользователе. Иногда нужно просто проверить гипотезу, просто показать заказчику и уточнить, то ли это, что он хотел, не затрагивая весь пул пользователей. Из этого вытекает необходимость тестирования, где мы смотрим, что у нас получилось. Проверяем сценарии на корректность и можем проверить производительность решения. Также, в конце концов, собираем обратную связь от пользователей. Не во всех компаниях у разработчиков должен быть доступ к бизнес-данным, и их нужно оградить от этих данных. Если мы ведём разработку на одной среде с пользователями, то изолировать данные не получается.

Жизненный цикл решения


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


Планирование. Собираем данные, планируем, как будем делать, разрабатываем архитектуру.

Разработка. Разрабатываем, делаем отладку, проводим ревью кода и проверяем качество на уровне разработки.

Тестирование. Тестировщики изучают, насколько выполняются бизнес-цели, и показываем заказчику. Формируем документацию.

Эксплуатация. Публикация для пользователей, осуществление настроек, в т. ч. прав доступа, и сбор обратной связи при эксплуатации.

Схема цикла CI/CD
Доставка фокусируется на этих шагах. И если это происходит один раз, то достаточно этих этапов, но если это происходит постоянно, то это становится бесконечным процессом. То есть происходит постоянная доработка старых решений, создание новых. Это значит, что для успешной работы этот цикл должен быть как можно короче и с минимальными накладными расходами.

Подходы к low-code разработке и доставке в ELMA 365


Для решения задачи по оптимизации жизненного цикла разработки существует 2 подхода.

Разработка на живую. Выглядит страшно, но для некоторых не критичных решений он подходит. Мы лишаемся всех проблем с доставкой, не задумываемся над тем, как правильно сделать решение. И если бизнес от ошибок не рухнет, то можно отлаживать на рабочей системе. Отладить мы сможем. Если что-то пойдёт не так, то пользователь может потерпеть.

Второй подход — это разработка с несколькими средами.

Окружения

Использование нескольких окружений. Когда мы создаём не одну платформу ELMA, а несколько для доставки результатов разработки. Мы рекомендуем использовать 3 стенда:

• среда разработки – где происходит непосредственная разработка и создание решений;

• среда тестирования – где подключаются тестировщики и осуществляется демонстрация бизнес-заказчику;

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

Иногда добавляют стейдж-среду, где проверяется корректная работа на актуальных данных, перед продуктовой средой.

Архитектура

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

• что-то мы можем из стора поставить, но для нас это как готовые внешние компоненты;

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

Изоляция решений и совместная разработка

Разделы и модули можно объединять в пользовательские решения. Разделы и модули лучше всего группировать в решения. Это нам позволит формировать зависимости между решениями и доставлять их по частям, так как не всегда получается всё в одном разделе уместить и приходится разбивать. Решения нам помогут эту особенность обходить. Желательно формировать решения по принципу: одна бизнес-функция, одно решение. Нужно стараться не использовать процессы или подобное на уровне конфигурации, а уносить всю эту логику на уровень решения. Это позволит легко переносить на другие площадки всю логику. Более подробные рекомендации находятся в low-code book, где можно познакомиться с информацией и рекомендациями по разработке.

Ручной перенос решений

Ручной перенос нам позволяет интерфейс платформы. Отмечаем, что переносим, система проверяет, можно ли это выгрузить. Если у нас есть какие-то ошибки, связанные с зависимостью, то система предложит добавить зависимости. В результате мы получим ELMA- пакет, то есть отдельный файл.

ELMA365pm

Инструмент, который больше подходит для компаний, у которых сильный IT-отдел, компаний, которые профессионально занимаются разработкой, – это ELMA365pm. Консольное приложение, которое также умеет загружать-выгружать решения как в веб-интерфейсе. Помимо этого, приложение умеет распаковывать решения, то есть разложить на отдельные файлы то, что было реализовано в low-code, и позволяет работать off-line с этим решением. Например, это удобно для код-ревью. Мы можем открыть файлы решения в любимой IDE и поправить то, что мы хотим. А самое главное – это можно использовать для внешней системы контроля версий Gitlab или Gitea. С помощью ELMA365pm можно автоматизировать процесс CI/CD, т.е. процесс непрерывной выкладки и доставки нашего решения.

Новое дерево решений

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

CI/CD

Допустим, есть несколько команд со своими задачами и есть 3 окружения DEV, TEST, PROD. Как всё происходит? Команда делает свою задачу, потом с помощью утилиты ELMA365pm делает выгрузку, распаковывает это решение и загружает в систему контроля версий, где уже настроен специальный пайплайн. Пайплайн соберёт это решение. Мы проверим, насколько оно импортируется-экспортируется. Если у нас взрослые процессы и мы проводим код-ревью, то здесь эти же инструменты помогут нам осуществить код-ревью. Затем команды смогут синхронизироваться между собой на сервере DEV и использовать общую кодовую базу. После того как мы накопили фичи, мы сливаем это на среду тестирования, где подключаются тестировщики. Далее могут происходить какие-то автоматизированные тесты, ещё что-то. В результате мы должны получить отлаженное готовое решение, которое не страшно выгрузить на продакшн. Выгрузка на продакшн. В результате решение начинает работать у всех пользователей.

CI/CD. GitLab
Предлагаю более детально ознакомиться со статьями по настройке данного пути на примере GitLab:

• Рекомендации по Low-code DevOps;
  
• Gitlab Runner для распаковки e365;
  
• Gitlab Runner для организации Dev-Test-Prod.

Low-code CI/CD

Для команды, не готовой себе ставить GitLab, мы хотим предложить новый инструмент low-code CI/CD, в котором уже в графическом виде можно настроить автоматизацию выгрузки решений между средами разработки.

Интерфейс настройки привязок Low-code CI/CD

Начинается всё с настройки: устанавливаем связь между серверами, указываем, как подключиться к другой площадке. Это у нас называется привязками.

Интерфейс настройки профиля переноса Low-code CI/CD

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

Интерфейс настройки объектов переноса Low-code CI/CD

Указываем объекты, которые переносим.

Интерфейс сравнения конфигураций Low-code CI/CD

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

Интерфейс экспорта Low-code CI/CD

Сам экспорт выполняется одной кнопкой. Экспорт выполняется в фоновом режиме, и в конце нам предоставляется лог с ходом процесса. Нажимаем «Выполнить» и можем продолжать работать в системе.