Как организовать деплой связанных микросервисов?

Question

[raiboon]

Периодически всплывает, что внесли изменения для какой-то фичи в несколько микросервисов.
Счастливые мы выкатываем их в прод и что-то отваливается, потому что какой-то сервис забыли.
Как избежать такого?
Технически? Административно?
Проект в жира, деплой через concource, репы в битбакете.

Comments

[nApoBo3]

У вас не микросервисы, а распределённый монолит. Микросервисы без значительных отказов переживают раздельный деплой.
Или собирайте с монолит или делайте микросервисы, иначе будет страдать.

Answer 1

[Dmitry Roo]

Сокращайте время доставки кода на прод - тогда и забывать ничего не будете

Answer 2

[Vitaly Karasik]

1) Как уже намекнул nApoBo3, не должно быть проблемы обновить один микросервис - т.к. это не должно ломать совместимость с остальными, как минимум на несколько версий.
2)

Счастливые мы выкатываем их в прод

- как уже сказали, должно быть тестовое (staging, pre-production, your-name-it) окружение, чтобы деплоить туда и тестировать - хотя бы вручную, лучше автоматически
3) деплой должен быть автоматическим, со всеми зависимостями, чтобы ничего не забывалось

Comments

[raiboon]

1. Только в мире розовых пони все изменения совместимы и обратимы.
2. На стейджингах все было выкачено и протестировано.
3. У вас такое есть? Как вы предлагаете настроить пайплайны, чтобы выкатка сервиса выкатывала зависимые?

[Vitaly Karasik]

А как вы деплоили на staging?

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

В mono-repo это просто - merge в branch для деплоя нужные версии нужных компонент, и они деплоятся одновременно.
Как сделать такое с независивыми репозиториями - я подумаю, навскидку ничего умного сказать не могу.

Только в мире розовых пони все изменения совместимы и обратимы

Обратимы - уже труднее, но совместимы - AFAIK это стандарт в микросервисах, насколько понимаю без этого микросервисы только создают проблемы, и не дают ничего хорошего.

Disclaimer: я не программист и не архитект, просто как devops freelancer сопровождаю много разных проектов.

[Vitaly Karasik]

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

Впрочем, у меня есть идея. Но не про поддержание где-то таблицы зависимостей.
А просто иметь одноименный branch ("production" для прода, например) во всех репозиториях, и всегда деплоить все сервисы из него. А сервисы версия которых не изменилась с прошлого деплоя, автоматически останутся с той же версией (насколько помню, в K8S это легко делается).

Answer 3

[Александр Прохорович]

"в прод и что-то отваливается"
А тестовый контур? Хорошая практика при выкатывании обновлений тестировать сначала весь основной функционал, как раз проверить, что ничего не отвалилось. Даже если изменения казалось бы не затрагивают эти области. И только потом в прод.
Еще можно, например, иметь таблицы зависимостей, чтобы знать, что проверять при том или ином изменении.

Comments

[raiboon]

На тесте все работало, а вот в прод не докатили.