Andrewavo

Допустим мы изменили микросервис А, изменения потребовали изменение Gateway

Этого не должно быть в микросервисной архитектуре, сервисы должны быть независимыми.
Варианты: использовать feature flag, обратная совместимость и т.п.

Например https://medium.com/@denhox/managing-version-depend...
"If deploying a new version of a service requires deploying new versions of other services at the same time, you’re probably doing microservices wrong."

Делаете три окружения: develop, staging, production. Develop - WIP, то, над чем сейчас идет работа. Staging - следующий стабильный продакшен. Тестирование отдельных фич можно проводить как в рамках staging так и в develop. Еще можно завести отдельный testing - туда отдельно вливать и деплоить изменения конкретно для тестирования. Работа ведется в рамках рабочего процесса github flow. Для каждого окружения поднимаете все нужные сервера и сервисы. Настраиваете автоматический деплой по PR в ветку для develop/testing/staging. Настраиваете автоматический запуск тестирования, при этом если тесты не проходят - деплой тоже не происходит. Деплой в production запускается либо по событию "релиз" либо вручную. Кроме того, сам деплой в production настраивается пошагово с возможностью отката на предыдущую версию. В целом же, рекомендую сделать декомпозицию вашего решения и рассмотреть возможность разделить ваш шлюз на несколько независимых компонентов/модулей.

Делайте разработку в отдельных ветках, сливайте в девелоп уже при завершении разработки и перед подготовкой к релизу.