Я работаю в команде, которая разрабатывает различные API (имел oop echosystem, scala язык программирования, Gradle для управления зависимостями и доставки в репозиторий Maven).
Некоторые API имеют зависимость кода между собой, так как мы работаем в разных репозиториях, API-интерфейсы которых зависят от других, использующих maven.
При таком подходе возникают серьезные проблемы с синхронизацией версий:
- API
A используется API B и C (оба используют A v1.0); API D использует B, C, поэтому косвенно зависит от A (от обоих B, C).
Если мы обновим до A v2.0, мы можем обновить B для использования A v2.0 и затем обновить D для использования более новой версии B, что вызывает ошибку зависимости, потому что теперь D имеет две разные версии A - A v2.0 из B и A v1.0 из C.
Это происходит потому, что у нас нет способа синхронизации между нашими версиями API и мы не имеем правильный систематический способ вручную обновить все проекты, использующие A прямо или косвенно, или даже знать о них (трудная задача, когда у вас много проектов API и зависимостей). - Разрабатывая
A, мы не можем проверить, хорошо ли он интегрируется с B, C, D без проверки вручную, потому что A не должен быть знаком с B , C, D, поэтому мы рассчитываем на наши модульные тесты.
Иногда мы обнаруживаем, например, что C плохо совместим с новой версией A, поэтому теперь мы должны выпустить Исправление для A. У нас нет единственного истинного источника контроля над версиями между нашими API. Было бы полезно, если бы кто-то мог автоматически сказать, какие версии работают друг с другом организованно, как:
'A': 2,0
'B': 1,4
'C': 1,2
'D': 3,0
Я знаю, что эта проблема кричит " используйте MONOREPO! ", но мы хотели бы управлять более старыми версиями некоторых API и контролировать, когда их обновлять , если мы использовали monorepo, обновление A автоматически обновит B, C, D, так как теперь они импортируют A напрямую, без какого-либо надлежащего независимого управления версиями.
Использование monorepo с разными ветвями для разных версий также вариант, но будет очень трудно управлять разными версиями разных API в разных ветвях. имен, поскольку нет единого продукта с версией, с которой мы можем связать.
Мы могли бы упаковать все разные версии в одну общую версию API, как в примере 3, но все еще трудно управлять d Версии ifferent API в одном репо (на самом деле сложнее логически упаковать их вместе, работая в разных репо, что является частью моего вопроса о том, как это сделать хорошо).
Я понимаю, что я должен принять некоторые преимущества и недостатки, которые дает выбор monorepo / multirepo, поэтому предположим, что мы остаемся с multirepo и не жалуемся на обновление версий вручную для каждого проекта и решение проблем несовместимости, спрашивает о лучших подходах к управлению различными версиями в нескольких репозиториях, чтобы облегчить некоторые проблемы, которые автоматически выполняются при выборе multirepo.
Подводя итог, что вы считаете лучшим Подход (технически и культурно для командной работы) к управлению версиями через API нескольких репо в зависимости друг от друга, разработанный одной командой?