Сборка в Gitlab как маркер здоровья архитектуры
Не так давно мне довелось настраивать СI/CD для среднего по размеру проекта, состоящего из ±20 микросервисов и 5 переиспользуемых библиотек. Изначально все микросервисы и библиотеки жили в собственных репозиториях и я настроил CI/CD индивидуально для каждой репы, вынеся общие скрипты и настройки в отдельный проект. Так мы пожили какое-то время, после чего пришла идея объединить все в монорепу, для удобства сопровождения и большей прозрачности при разработке.
Для монорепозитория CI/CD был реализован следующим образом: каждый сервис содержит свой файл .gitlab-ci.yml с описанием пайплайна, при этом корневой файл сборки проекта содержал директиву включения/исключения CI-файлов конкретных сервисов в зависимости от того были ли в них или их зависимостях изменения.
И была среди прочих компонентов одна непримечательная библиотека common-dto. Из названия создаётся впечатление, что в ней должны лежать различные верхнеуровневые абстракции для DTO, от которых наследуется большая часть сервисных DTO. Однако все оказалось не так просто. Ещё во время сбора монорепы я обратил внимание, что в этой библиотеке как-то многовато специфических DTO, которые принадлежат конкретным сервисам. Оказалось, что туда были положены все DTO, используемые более чем в одном сервисе.
Не сложно догадаться, что от common-dto зависили ВСЕ сервисы. При этом вопреки правилу чистой архитектуры, которое гласит, что компонент от которого зависят многие должен быть наиболее стабильным, common-dto дополнялась буквально в каждом втором merge-request’e, из-за чего все компоненты системы пересобирались (это занимает ± 20 мин).Таким образом сборка проекта в очередной раз подсветила проблемную архитектуру.
Что вы думаете о конвеерах CI/CD как маркере архитектуры?
Были бы вам интересны подробности настройки CI/CD для Java монорепозитория и как в итоге была отрефакторена common-dto?
Пожалуйста напишите в комментариях.
