не знаю поможет тебе или нет мой опыт, но я делал следующее
1. репо сервиса, содержит докер файл и гитлаб сий скрипт сборки, деплой сервиса выполняет этапы сборки и тегируя нужной версией контейнер складывает его в реджистри (соответственно таких сервисов н штук)
2. репо деплоя, ансибл который доставляет композ файл на хостовую машину, занимается пуллингом контейнеров и настройкой версий (энвироменты, которые зацеплены в композ файле) , так же через этот репозиторий я управляю энвироментами внутри самих сервисов, бренчи репозитория различаются по настройкам и отвечают за выкатку на разные стенды.
Что мне нравится в этой архитектуре, выкатка релиза происходит единомоментно, нет ситуации когда первый апдейченый сервис уехал пол часа назад и все лежит пока не приедет последний...
что мне не нравится, больше телодвижений чем обычно, для кластерного деплоя надо додумывать эту схему.
