При разработке решений для клиентов на практике мы столкнулись с несколькими проблемами. Первой из таких проблем можно назвать хранение исходных кодов решений. При длительной разработке или разработке несколькими командами на проектах нужна возможность видеть историю, понимать, что именно изменилось в новой версии, кто внёс те или иные изменения в код, понимать причины изменений и т. д. К тому же для компаний-интеграторов актуальна тема с использованием существующих наработок, библиотек функций и решений.
Вторым пунктом в списке проблем отметим организацию code-review. Процесс проверки кода командной разработки перед выпуском уже давно используется в мире. Возможность поймать ошибку, сравнить код с предыдущими версиями, обсудить тонкие моменты, научить новичков — это то, для чего команды используют code-review. Процедура несомненно важная, так как позволяет осуществлять контроль и предотвращать ошибки на этапе разработки.
И последним в списке выделим автоматическую доставку решения до рабочего (боевого) сервера. Непрерывная доставка в мире современной разработки становится едва ли не обязательным пунктом при разработке решений. Чтоб снизить простои команд, уменьшить ошибки, связанные с человеческим фактором, доставлять проверенные решения, обеспечивать непрерывность разработки, нужен CI/CD и схема Develop — Test — Production.
![[IMG]](https://cms.elma365.com/assets/99399ced-ca7a-49e1-9afe-fbf88f422818?width=712)
Для решения этих проблемы мы ввели понятие Low-сode DevOps и разработали утилиту elma365pm. Как вендор рекомендуем вам следующее. Совместно с нашими партнёрами мы выработали рекомендации к использованию данной утилиты и разработке решений. Для самостоятельного изучения можно ознакомиться со статьёй «Инструмент для построения Low-code DevOps практик».
Хранение исходных кодов и организация code-review
С помощью утилиты elma365pm можно экспортировать решение со стенда, распаковать файл. Эти две операции помогут нам настроить классический процесс code-review.
План следующий: разработчик решения выгружает со стенда файл экспорта *.e365, закидывает коммит с этим файлом на git-сервер. Далее на сервере срабатывает автоматизация, которая предоставляет нам доступ к исходным кодам сценариев.
В командах разработки, с которыми мы работали на проектах, встречались следующие подходы. Одни команды пропускали этап code-review и решали проблемы на этапе тестирования по мере их выявления. Другие команды использовали практику парного программирования, когда после завершения разработки два сотрудника просматривают всё решение, обсуждают тонкие моменты, и в итоге формируется список замечаний/исправлений. Исполнитель уходит исправлять замечания, после чего шаг с проверкой повторяется. В целом такой подход работает для небольших команд.
Первый шаг, который нужно сделать, — выбрать систему для хранения исходных кодов. Мы рекомендуем использовать GitLab, так как у данного сервиса есть бесплатная версия, большое сообщество и широкий набор дополнительных инструментов (организация code-review, хранение образов, возможность настраивать свой CI/CD и др.).
В стандартной установке без доработок можно будет хранить исходники в виде бинарных файлов. По таким исходникам не очень удобно искать, но уже можно вести историю версий с описанием изменений.
![[IMG]](https://cms.elma365.com/assets/83a222f4-d79f-42e4-bd70-4fb1e43f46fc?width=712&height=569)
Следующий шаг для организации code-review — научиться распаковывать файл e365. По ссылке доступна статья с подробной инструкцией — «Как настроить GitLab для распаковки файлов e365». После применения этого подхода вы получите возможность смотреть исходные коды и видеть всю структуру решения.
![[IMG]](https://cms.elma365.com/assets/5a9cb5f6-8a37-40de-ba38-1a74fb50160a?width=712)
Далее уже применяем стандартные подходы к организации code-review. В итоге мы имеем ветки с проверенными решениями.
![[IMG]](https://cms.elma365.com/assets/81ecc4b4-924a-4f81-87ac-4073caf288e7?width=712)
![[IMG]](https://cms.elma365.com/assets/5068920d-c24f-42fa-a71b-ab0f4696848a?width=712)
CI/CD для ELMA365
Для организации работы нескольких команд мы предлагаем следующую схему непрерывной интеграции и выкладки.
![[IMG]](https://cms.elma365.com/assets/3049541e-f387-4f9a-bd25-f7b0d49a1a29?width=712)
Architect (архитектор) — роль, которая отвечает за всю систему и её целостность.
Team_1, Team_2 — команды разработки.
Схема Develop — Test — Production (разработка — тестирование — эксплуатация) предполагает, что разработка и тестирование новых процессов ведутся не в рабочем окружении (где работают обычные пользователи), а в отдельных окружениях. В рабочее окружение переносятся только проверенные, протестированные решения. Develop — Test — Production увеличивает стабильность системы и удобство разработки.
Если разработка ведётся несколькими независимыми командами, для каждой команды может быть развёрнуто отдельное Development-окружение.
Доставка решения до Production-окружения
Разберём подробнее этапы доставки решения до Production-окружения. С подробной инструкцией по настройке GitLab вы можете ознакомиться в статье «Установка и настройка GitLab Runner».
Этап №1. Решение создаётся и тестируется командой разработки на своём собственном окружении, например Team-1.
![[IMG]](https://cms.elma365.com/assets/28777a61-e76f-4da4-91ce-1835aac7a843?width=712)
Этап №2. После того как команда решает, что решение готово, оно отправляется в ветку решения Task_1. Решение команды проходит первичную проверку и контроль внутри самой команды.
![[IMG]](https://cms.elma365.com/assets/50127185-8b86-4954-8764-f08ca0b74881?width=712)
Этап №3. Архитектор проводит code-review решения, после этого оно может быть отправлено на доработку или принято в ветку DEV. Система CI/CD может выгружать решения из DEV на специальное Development-окружение. По сути это проверка установки/обновления решения и совместимости с решениями других команд.
![[IMG]](https://cms.elma365.com/assets/9d237d1f-d76a-478a-be24-9a3102e60893?width=712)
Этап №4. По мере накопления бизнес-фич в DEV-ветке архитектор принимает решение о доставке версии на Testing-окружение. Выгрузка происходит автоматически, архитектору достаточно только отправить запрос на слияние в Test-ветку. Из данной ветки решения автоматически импортируются на Testing-окружение.
![[IMG]](https://cms.elma365.com/assets/46ec7ea4-fe33-4d78-b1c1-31dc710871c1?width=712)
Этап №5. После прохождения тестирования архитектор принимает решение о выпуске релиза на рабочее Production-окружение. Это происходит по аналогии с Test’ом: отправляется запрос из ветки TEST в PROD, откуда изменения уже автоматически попадут на Production-окружение.
![[IMG]](https://cms.elma365.com/assets/967219ce-0695-4d9a-8178-d1e1637378c6?width=712)
Выводы
Применение практики DevOps при разработке решений предоставляет командам следующие преимущества:
- Контроль. Исходный код теперь проходит проверку, к тому же команды могут добавить в pipeline автоматическую проверку решения на ошибки.
- Скорость. Доставка решения до конкретного окружения происходит автоматически, с минимальными задержками по времени. За счёт отдельного окружения для тестирования скорость разработки не снижается при выпуске релизов.
- Уверенность. Автоматическое тестирование, исключение человеческого фактора при переносе.
- Выгода. Работа машины дешевле, чем работа специалиста. Ошибки выявляются на ранних этапах, что снижает риск простоя рабочего сервера.
Последнее редактирование: 28 ноя 2022