Долгая история, много пространсв для улучшения и этим точно нужно заниматься, но сейчас нам надо выживать 🙂 Растём 15Х в год по пользователям от очень ненулевой базы, удваиваемся по людям который год подряд.

Такое может быть, но если делать graceful deploy, то не должно часто случаться. Если будет прямо бесить, то можно поставить lock на деплои и запуски тестов и выполнять всё это последовательно

Я слышал про такой вид тестов, когда ты тестируешь 3party API и его compatibilty

Я неправильно выразился, упал не деплой, а ошибка в приложении

Если научиться решать задачу “запустить на деплой не только свои тесты, но и тесты своих зависимостей” так, чтобы не переполнить все возможные очереди, то это тоже должно решаться. Иначе да, надо будет сидеть и разбираться, но если за staging есть нормальный надзор, то должно быть норм

Кст я писал такие интеграционные тесты Страйпа, создавал удалял платежки в sandbox

Точно

Тогда только мониторинги и graceful degradation...

Системы слишком сложные

одна из причин почему в некоторых случаях лучше жить на микросервисной архитектуре потому что у каждой команды свои требования к окружению и к организации работы. команда сама решает как ей работать.

поэтому стороить микросервисы и одновременно с этим одинаковый мир для всех команд звучит очень странно.

output от команды это задеплоеный код в прод, деплой в dev staging и подключене своего сервиса в системе мониторинга. все остальное они решат сами

Отличный диалог для fomo, кстати

Точняк.

Sandbox страйпа это копия прода, к которому команда страйпа относится точно так же как и к проду. Ты можешь его использовать для своих целей, но нет возможности диктовать какая именно версия нужна.

В мире микросервисов команда должна предоставить такой же sandbox для других

но нет возможности диктовать какая именно версия нужна.
Вроде как там api version прям в урле указываешь(2020-12-12)

так что привязка должна быть AFAIK

Ну хз, у меня другой опыт. Чем более унифицированы окружения — тем лучше. А микросервисами решается не задача уникальных потребностей к окружению, а задачи:
1. Оунершип рантайма (когда один большой монолит и что-то сломалось, то сложно понять кто должен чинить и в итоге чинят одни и те же)
2. Развязанный релизный цикл — если в монолите в мастер попадает бага, то конвеер релизов встаёт для всех
3. Уменьшение сложности системы — у монолита обычно много-много зависимостей на разные компоненты и это сложно понимать, поддерживать, скейлить. Понятно, что с микросервисами можно тот ещё ад сделать, но если хорошо подумать и последить, то можно этого и избежать

это чуток другое.

команда страйпа держит N прод версий и гарантирует их работу.

моя мысль в том, что тебе доступно только то что дают.

А, ну да

Это уже их зона ответственности

Поднять свой страйп inHouse 🙂

> output от команды это задеплоеный код в прод, деплой в dev staging и подключене своего сервиса в системе мониторинга. все остальное они решат сами
Тут тоже не могу согласиться, но тк я вроде вопрос задавал, то не буду спорить 🙂 Добавлю ссылочку на бложек любимого в этом чате Спотифая: https://engineering.atspotify.com/2020/08/17/how-we-use-golden-paths-to-solve-fragmentation-in-our-software-ecosystem/

В общем, если я правильно услышал мнение общественности, то схема “один Кубернетес в котором есть общий staging + для каждой команды по namespace для их песочницы” — это нормальный и достаточно дефолтный способ решения задачи.

Возникает вопрос, как сделать так, чтобы заданное приложение из общего staging ходило в моё приложение не из staging, а из песочницы (если я хочу проверить, что своим деплоем не поломаю клиентов), тут надо подумать.