+

двачуешь, получается =)

Блеск и нищета SOA архитектуры. Ваша задача легко решается, если заменить термин microservice на external service и представить как бы выгледело тестирование в таком случае.

Приложение которому нужен Stripe не может для своих тестов задеплоить Stripe определенной версии. Поэтому downstream использует тот upstream, который доступен и не может требовать ничего больше.

Самый простой способ это поднять dev staging environment к которому вы относитесь так же как к вашем production. В этом окружении живут сервисы из ветки main которые можно использовать для нужд разработки и тестирования.

У каждой команды есть свое CI окружение которое использует сервисы из dev staging. Если они хотят что-то протестировать то льют в свой CI, но возможности деплоить другие версии upstream микросервисов у них нет, потому что каждый микросервис живет своей жизнью и зависимый компонент ничего не знает о жизненном цикле своей зависимости.

Далее для юнит тестов мокаем - здесь нет альтернатив, потому что тесты обязаны быть быстрыми,  для интеграционных тестов поднимаем docker compose где это возможно, а для всех остальных тестов используем сервисы из dev staging.

лайк

но тоже есть свои нюансы

когда другие сервисы будут деплоить новый мастер/мейн для дева/стейджа, оно может упасть, и ваши тесты будуть падать

поэтому микросервисная архитектура не для всех. если сервис не может обеспечить backward/forward compatibility то стоит подумать нужна ли такая зависимость.

Вам лид саппорта не нужен? 6 лет опыта игрового саппорта, из них 4 в качестве лида второй линии, опыт поддержки международных проектов с аудиторией в 300к MAU, в том числе под ключ (от непосредственного общения с юзерами до разработки ТЗ для инструментов поддержки и написания всей саппорт документации, индивидуальной работы со сложными кейсами итд итп). Правда, денех хочу для саппорта много, от 80, иначе нет смысла из мейла уходить.

Залить багу

прям сейчас точно нет — у нас всего 6 человек в отделе + лид, пока справляются с запасом. Но будем скоро расширяться, может и появится потребность. Давай пока просто запишу контакт)

Блеск и нищета SOA архитектуры. Ваша задача легко решается, если заменить термин microservice на external service и представить как бы выгледело тестирование в таком случае.

Приложение которому нужен Stripe не может для своих тестов задеплоить Stripe определенной версии. Поэтому downstream использует тот upstream, который доступен и не может требовать ничего больше.

Самый простой способ это поднять dev staging environment к которому вы относитесь так же как к вашем production. В этом окружении живут сервисы из ветки main которые можно использовать для нужд разработки и тестирования.

У каждой команды есть свое CI окружение которое использует сервисы из dev staging. Если они хотят что-то протестировать то льют в свой CI, но возможности деплоить другие версии upstream микросервисов у них нет, потому что каждый микросервис живет своей жизнью и зависимый компонент ничего не знает о жизненном цикле своей зависимости.

Далее для юнит тестов мокаем - здесь нет альтернатив, потому что тесты обязаны быть быстрыми,  для интеграционных тестов поднимаем docker compose где это возможно, а для всех остальных тестов используем сервисы из dev staging.

Круто, спасибо за развёрнутый ответ. Твоё предложение хорошо резонирует с тем, что я и собираюсь сделать.
Но возникает технический вопрос: как лучше организовать “У каждой команды есть свое CI окружение которое использует сервисы из dev staging.”?

Можно поднимать свой Кубик для каждой группы и деплоить туда не совсем всё, а только их сервисы. Это уже лучше, но всё равно нужно будет плодить 100500 кубернетесов под каждую команду и этим не очень хочется заниматься.
Вот вопрос как раз в том, можно ли как-то космическими технологиями Кубернетеса решать это как-то более элегантно. Задача, кажется, не уникальная и запрос на это должен быть.

мы просто держали столько стейджей сколько команд

Круто, спасибо за развёрнутый ответ. Твоё предложение хорошо резонирует с тем, что я и собираюсь сделать.
Но возникает технический вопрос: как лучше организовать “У каждой команды есть свое CI окружение которое использует сервисы из dev staging.”?

Можно поднимать свой Кубик для каждой группы и деплоить туда не совсем всё, а только их сервисы. Это уже лучше, но всё равно нужно будет плодить 100500 кубернетесов под каждую команду и этим не очень хочется заниматься.
Вот вопрос как раз в том, можно ли как-то космическими технологиями Кубернетеса решать это как-то более элегантно. Задача, кажется, не уникальная и запрос на это должен быть.

у нас сейчас +- так, как описано выше - staging + prod куда льётся всё, uat - куда льётся часть, нужная командам. uat можно каждому выдать свой

в которые будет литься как раз не совсем всё