Рекомендации по Low-code DevOps

Хранение исходных кодов и организация code-review

С помощью утилиты elma365pm можно экспортировать решение со стенда, распаковать файл. Эти две операции помогут нам настроить классический процесс code-review.

План следующий: разработчик решения выгружает со стенда файл экспорта *.e365, закидывает коммит с этим файлом на git-сервер. Далее на сервере срабатывает автоматизация, которая предоставляет нам доступ к исходным кодам сценариев.

В командах разработки, с которыми мы работали на проектах, встречались следующие подходы. Одни команды пропускали этап code-review и решали проблемы на этапе тестирования по мере их выявления. Другие команды использовали практику парного программирования, когда после завершения разработки два сотрудника просматривают всё решение, обсуждают тонкие моменты, и в итоге формируется список замечаний/исправлений. Исполнитель уходит исправлять замечания, после чего шаг с проверкой повторяется. В целом такой подход работает для небольших команд.
Первый шаг, который нужно сделать, — выбрать систему для хранения исходных кодов. Мы рекомендуем использовать GitLab, так как у данного сервиса есть бесплатная версия, большое сообщество и широкий набор дополнительных инструментов (организация code-review, хранение образов, возможность настраивать свой CI/CD и др.).

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

Следующий шаг для организации code-review — научиться распаковывать файл e365. По ссылке доступна статья с подробной инструкцией — «Как настроить GitLab для распаковки файлов e365». После применения этого подхода вы получите возможность смотреть исходные коды и видеть всю структуру решения.

Далее уже применяем стандартные подходы к организации code-review. В итоге мы имеем ветки с проверенными решениями.

CI/CD для ELMA365

Для организации работы нескольких команд мы предлагаем следующую схему непрерывной интеграции и выкладки.

Architect (архитектор) — роль, которая отвечает за всю систему и её целостность.

Team_1, Team_2 — команды разработки.

Схема Develop — Test — Production (разработка — тестирование — эксплуатация) предполагает, что разработка и тестирование новых процессов ведутся не в рабочем окружении (где работают обычные пользователи), а в отдельных окружениях. В рабочее окружение переносятся только проверенные, протестированные решения. Develop — Test — Production увеличивает стабильность системы и удобство разработки.

Если разработка ведётся несколькими независимыми командами, для каждой команды может быть развёрнуто отдельное Development-окружение.

Доставка решения до Production-окружения

Разберём подробнее этапы доставки решения до Production-окружения. С подробной инструкцией по настройке GitLab вы можете ознакомиться в статье «Установка и настройка GitLab Runner».

Этап №1. Решение создаётся и тестируется командой разработки на своём собственном окружении, например Team-1.

Этап №2. После того как команда решает, что решение готово, оно отправляется в ветку решения Task_1. Решение команды проходит первичную проверку и контроль внутри самой команды.

Этап №3. Архитектор проводит code-review решения, после этого оно может быть отправлено на доработку или принято в ветку DEV. Система CI/CD может выгружать решения из DEV на специальное Development-окружение. По сути это проверка установки/обновления решения и совместимости с решениями других команд.

Этап №4. По мере накопления бизнес-фич в DEV-ветке архитектор принимает решение о доставке версии на Testing-окружение. Выгрузка происходит автоматически, архитектору достаточно только отправить запрос на слияние в Test-ветку. Из данной ветки решения автоматически импортируются на Testing-окружение.

Этап №5. После прохождения тестирования архитектор принимает решение о выпуске релиза на рабочее Production-окружение. Это происходит по аналогии с Test’ом: отправляется запрос из ветки TEST в PROD, откуда изменения уже автоматически попадут на Production-окружение.

Выводы

Применение практики DevOps при разработке решений предоставляет командам следующие преимущества:

• Контроль. Исходный код теперь проходит проверку, к тому же команды могут добавить в pipeline автоматическую проверку решения на ошибки.
• Скорость. Доставка решения до конкретного окружения происходит автоматически, с минимальными задержками по времени. За счёт отдельного окружения для тестирования скорость разработки не снижается при выпуске релизов.
• Уверенность. Автоматическое тестирование, исключение человеческого фактора при переносе.
• Выгода. Работа машины дешевле, чем работа специалиста. Ошибки выявляются на ранних этапах, что снижает риск простоя рабочего сервера.