Igor Karachentsev, верно я вас поняла, что авторизовавшись в одом сервисе, в других тоже придеться авторизовываться? максимум можно сделать хранение сессии только для одного клиента.
Грубо говоря, пошарить авторизованные данные одного клиента, для других клиентов - не получиться ?
Станислав Макаров, может это больше организационный момент или что-то у меня не складывается
История
Есть milestone = сейчас у нас интерпретируется, как выпускаемая версия релиза. Куда могут входить разные версии сервисов, каждый сервис используем TBD.
Планируется внести некий функционал в выпускаемый релиз.
Соответственно в клиентском и серверном приложении и всех связанных сервисах, которые требуют изменений , заводится ветка, название которой совпадает с планируемым релизом, к примеру 2.3.
И в это и заключается сложность, т.к могут использовать доп. сервисы который должны попасть в этот релиз, но они не требуют изменений, у них версия 1.1. Да и клиенту может не требоваться никаких изменений, но ему все равно заводится ветка, название который совпадает с выпускаемым релизом, для контроля совместимых версий.
Плюс могут разрабатываться, несколько параллельных версий релиза.
спасибо за правку,
в вашем предложении, если я правильно поняла, предполагается, что из апи выгружаются миграции, в виде sql скриптов, а гит в данном случае является синхронизатором, между базой кода апи ( где лежат модели и миграции ) и сервисом выполняющий создание тенанта? верно
Дмитрий, при создании тената, создается только БД , на одном в каком-кластере, база кода ( апи сервиса ) не знает когда нужно применять миграции , в ней только хранится список миграций
```в любом выбранном решеннии - есть компромисы: чем готовый жертвовать и что точно нужно учитывать ```