Независимая выкатка микросервисов. Как сделать так, чтобы на продакшен не попадал неготовый код?

Question

[Andrewavo]

Есть проект, разделённый на микросервисы, единая точка входа микросервис Gateway. Допустим мы изменили микросервис А, изменения потребовали изменение Gateway. Параллельно велась работа над микросервисом B, которые тоже потребовали изменения в Gateway. B еще не готов и работает некорректно. Для выкатки A на production мы вынуждены выкатить Gateway, но туда попадут также незаконченные изменения для B, то есть мы не можем независимо выкатить A. Как решить проблему независимой выкатки A?

Answer 1

[Vitaly Karasik]

Допустим мы изменили микросервис А, изменения потребовали изменение 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."

Answer 2

[Belvarm]

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

Comments

[Andrewavo]

Это одно из решений, которое мы рассматриваем. Некоторые фичи, достаточно трудоёмки, разработка может занять пару месяцев. Если разрабатывать в отдельных ветках, то полный развёрнутый проект на dev не будет их содержать. QA тестирует частично сделанную функциональность в среде dev. Как обеспечить тестирование QA частично сделанной функциональности?

[Belvarm]

Andrewavo, в таком случае мы просто держим несколько окружений, один чистый dev стенд с продуктом, другие окружения собранные с нужных веток

Answer 3

[VoidVolker]

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