Командная разработка на платформе AggreGate + Git
Приветствую, меня зовут Сергей, я основатель независимого сообщества Low-code разработчиков на платформе AggreGate (далее Платформа).
В этой статье изложу взгляды на организацию командной разработки коммерческих продуктов на Платформе с использованием Git.
Проблема
Уверен, что каждый, кто достаточное время занимается коммерческой разработкой более-менее крупных проектов на Платформе не раз сталкивался со следующими проблемами:
- Кто-то внёс изменение, которое поломало часть функциональности решения, но не получается отследить момент и точку поломки, и приходится пересматривать все "контексты", долго и кропотливо отлаживая и тестируя все функции, структуры данных, наборы правил, интеграции и пр.
- Или известно, кто и что сломал, но не осталось бекапа, на который можно было бы быстро откатиться и восстановить работоспособность.
- А может просто в какой-то момент "контекст" сломался по неустановленной причине (довольно частая проблема), и его надо переделывать с нуля.
- Миграция изменений dev -> stage -> prod, делается вручную, путём переноса файлов конфигурации контекстов, и каждый раз есть шанс что-то забыть, не перенести, или перенести ещё не готовое и пр.
- Нет прозрачности в процессе разработки, у менеджера нет инструментов, чтобы на ежедневной основе отслеживать прогресс. Приходится либо бегать за инженерами и спрашивать, что он делает сегодня, или просто надеяться что всё будет готово вовремя.
- Сотрудник уволился, оставив свои наработки на проде, которые невозможно быстро "подхватить" и передать на сопровождение другому специалисту.
это лишь несколько примеров, думаю Вы поняли о чём речь.
Подход к решению
Все описанные выше проблемы в "классической" разработке устраняются в самом начале проекта, за счёт подключения системы контроля версий (Git).
Точно также процесс разработки должен быть устроен и для проектов на Платформе AgrgeGate. Подключение Git - это один из первых шагов, который необходимо сделать при старте нового проекта.
Проведу аналогию с этапами развития платформы 1С, в которой командная разработка очень схожа, и прошла примерно те же этапы и проблемы:
Этапы развития 1С
1 Локальная система контроля версий (общая папка или структура каталогов)
2 Хранилище конфигураций
3 Конфигуратор + Git
Схожие этапы развития Платформы AggrGate
1 Контекст "Приложение"
2 Магазин приложений
3 "Приложение" + Git
Организация процесса разработки
Для эффективной организации работы мы следуем нескольким простым но выжным принципам и ограничениям:
1 Для каждого проекта создаётся центральный репозиторий Git в корпоративном или публичном сервисе, и контекст "Приложение" на dev, stage, prod серверах (и на рабочих станциях каждого инженера, если работа ведётся локально). Например публичный репозиторий.
Крайне рекомендую давать одинаковое имя репозиторию и Приложению, это значительно упростит автоматизацию
2 Пути директорий Приложения на локальном сервере должны формироваться по единому шаблону для всех серверов. Нам хватает простой структуры каталогов: "applications/[appName]".
3 На все серверы Платформы устанавливается относительная модель, которая привязывается к Приложению, и реализует автоматизацию взаимодействия с Git через пользовательский интерфейс.
4 После внесения минимально значимого изменения инженер в обязательном порядке делает коммит с понятным сообщением, и отправляет изменения в центральный репозиторий. На наших серверах это делается одной кнопкой, которая экспортирует файлы конфигурации на диск, индексирует их, делает локальный коммит, пушит изменения в центральный репозиторий и обновляет описание приложения в соответствии с хешом последнего коммита.
5 "Раскатка" новой версии на сервер также происходит только через Git при помощи команды git pull и последующим обновлением. Этот шаг на деле может оказаться довольно непростым, так как требует определённого уровня строгости в организации ресурсов Приложения, и по началу будет желание поправить что-то руками. Однако в итоге, при увеличении строгости в некоторых процессах , качество продукта только выигрывает.
Эффект от перехода на Git
Главный эффект - спокойствие команды и менеджмента. Знание того, что при любой проблеме можно откатиться на один или несколько коммитов назад не только ускоряет разработку, но и даёт некоторую безопасность для "творческого" поиска.
Процессы разработки стали прозрачнее. В каждом коммите есть ссылка на задачу, при пуше в master вся команда видит соответствующее уведомление в Телеграмм и обновление архитектуры в PlantUML (это тема для отдлеьной статьи). Менеджеры более чётко понимают темп движения каждого инженера и команды в целом.
Общее улучшение архитектуры проекта. Происходит естественным образом, поскольку как я уже упоминал, более структурированная организация процессов, улучшает и технологическую часть проекта.
Масштабируемость и переносимость продуктов и отдельных модулей. Развертывание типового приложения под нового пользователя занимает несколько кликов мыши, и не требует ручной миграции файлов с сервера на сервер. В нашей команде это делается через "магазин модулей" - специальный интерфейс, доступный на любом сервере, и позволяющий быстро встроить типовой модуль в новое решение.
Ну и по моему мнению, организация владеет только тем исходным кодом, который размещён в её системе контроля версий. В ином случае владельцем кода является его автор, если вдруг он уволится, то зачастую проще будет сделать всё с нуля, чем пытаться разобраться в его наработках, распределённых по группе серверов.
Открытые вопросы
- В настоящий момент каждый инженер может запушить изменения в master. Вопрос необходимости выделения "фича" веток остаётся открытым.
- Мы работаем над правильным подходом к версионированию решений.
- Контекст "Приложение" имеет некоторые функциональные решения, которые пусть и не блокируют описанные подходы, но вызывают некоторые неудобства (тут рассчитываем на Вендора).
Спасибо всем кто дочитал!