в ситуации, когда команда работает над очередной версией бд, но часть фич готова, а часть - нет, и нам необходимо перенести только готовые фичи на тест с разработки. Черри пики, создание отдельных джобов на миграции разных схем в бд или что-то ещё?
Что значит очередная версия бд? У вас какие то лимиты на изменения схемы ?
Кейс. Разработчик Вася делает фичу А, а разработчик Петя делает фичу Б. Вася и Петя тестируют свои фичи на полигоне разработки. Доставка изменений на дев осуществляется тоже через флайвей. Полигону разработки соответствует ветка дев в гите. К моменту релиза Вася свою фичу сделал и готов отдать её, а Петя не доделал и не готов нести её дальше. Какой механизм здесь лучше использовать, чтобы дать возможность нести фичи избирательно? Или может саму концепцию следует пересмотреть
Ну если совсем заморочиться - каждому по полигону и по ветке в git на фичу. Затем интеграционный стенд - убедиться что готовые фичи друг друга не поубивают и собравшись вместе прод не задушат. А вот по разнице между оттестированным интеграционным стендом и продом уже придумывать миграцию.
(Пожав плечами) до начала интэграцыонных тэстов у команды должна быть рабочая процэдура миграцыи прода в её прндставление. Соответственно, раскатываете прод и запускаете миграцыю.
А Вы такое видели в реальности? У меня система, предположим, 10 микросервисов в докерах, одна виртуалка 32 гб, плюс на ней же тестят по разработчики не только базы, но и приклада. Это сколько нужно таких виртуалок развернуть? По идее столько, сколько программистов, а это че то как-то многовато
Нене, это ещё норм. Вот когда на каждую фичу/ветку своя полная виртуалка - вот тут повеселее ;)
Не пойму, это шутка или нет😂 Ресурсы анлимитед?
А как вы их вообще вместе состыковываете? Мы тут неделю за java bindings всей толпой гонялись. Если б базисты на прикладников а прикладники на базистов кивали ввек бы не нашли.
А вы это над реальными данными и с реальной нагрузкой гоняете?
Базовых и прикладных погромистов
Не, на разработке потока реального нет, только синтетический лайтовый
А зачем тогда столько ресурсов?
Потому что микросервисы завернуты в докеры со стандартным лимитом на ресурсы
Не силён в виртуализации, но помню что переподписка по cpu там стандартная практика. Так может и для памяти что-то подобное придумали? Мне недавно показывали насколько хорош сжатый swap на гипервизоре.
Ну у нас каких то противоречий вроде пока нет, все делают свою часть. Если прикладникам что-то нужно в базе, то сами могут дописать. Правда БДшники в код не лезут
Обсуждают сегодня