да

но требует привыкания

да

ансибл нужен чисто ноды для докера катать

ну и регистри чем-то нужно развернуть )

А терраформ?

мне хашикорповские продукты не заходят

Ага, докер почти полностью заменяет провизионер. Но файрвол например через докер не настроишь.

да, с этим есть небольшое говно пока

надо идти и ручками создавать ноды

и потом уже их катать

терраформ может быть удобнее в этом плане

но не всё сразу

ансибл для провиженинга

номад для деплоя

и оркестрирования :)

у нас в ранчер деплоится прямо из CI

так что у нас вопрос деплоя не стоит совсем

зря вы так

ой блядь

щас начнётся

из CI тестировать/деплоить образ вкусно же.

не бывает никогда деплоя с ломающими миграциями?

советчики ёбанные, которые не знаю какую задачу мы хотим решить

В моей практике не было, но мне кажется что это просто и удобно.

не бывает никогда деплоя с ломающими миграциями?

нет, не бывает

ломающие миграции запрещены, no shit

ну тогда заебись повезло

Можно миграции так писать чтобы они не ломали код.

пушо монга

нет схемы, нет миграций

ахаха

ну тогда окей

RDBMS-крестьяне смотрят и завидуют

надо будет мигрировать, будет фоновый процесс, который будет это мягенько делать

апдейтами

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

бывает так что не изябнутся

чтобы старый код с новой схемой нормально работал

редко-редко

приходится либо с даунтаймом

либо с двумя деплоями

согласен что редко

но достаточно часто чтобы отказаться от деплоя из CI

да, автодеплой отключил :(

если считать что из базы никогда ничего не удаляется, а только добавляется, сразу становится очень легко и просто жить

как-то не по феншую в базе мусор держать

его можно вычищать эпизодически конечно

с миграциями ебаться дороже

как-то не по феншую в базе мусор держать

так он не мусор, он гарант успеха

гарант успешного роллбэка

йеп

гарант того что даже первая версия кода будет работать с существующей базой

по мне так схема бд идет в ногу с кодом

у первой версии должна быть и соответствующая схема

а вот когда из-за всякого говна

будет перфоманс в жопу жалить

побежите на проде alter table делать :)

индексы там хуиндексы

у первой версии должна быть и соответствующая схема

схема же для развертывания версии ну пусть йопп предлагает хранить все но можно же найти золотую середину

из-за которых планировщик запросов хуево работает

я вот держу старые данные до тех пор пока не повяляется уверенность что все работает потом сношу

уверенность иногда зреет месяцами

мы в среднем так-же делаем

но автодеплой слишком ссыкотно

в пятницу вечером какой-нибудь мудак запушит в мастер

ERROR: S client not available

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

а потом с горящей жопой в субботу бегаешь

а вот когда из-за всякого говна

вот когда будет, тогда и побежим

тебе сколько лет, что ты всё ещё предварительно оптимизируешь?

я не оптимзирую

оптимизируешь

дело не в оптимизации

просто не люблю хлам

а не суй хлам в базу

это как в коде мертвый код держать

или закомментированный

DDDD - Delayed Decision Driven Development

код != данные

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

а не тяп-ляп-хуяк-и-так-сойдёт

согласен

но есть случаи как выше озвучено

что старый данные идут во вред

те же индексы

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

в монге неиспользуемый индекс занимает место и всё

никакого импакта на производительность, если поля нет в запросе

те же индексы

ну видно же сразу когда инсерты начинают доставлять

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

постгрес вообще говнище

причем на селекте

они проебали все полимеры

я же выше сказал что в случае с монгой

Мне про один проект рассказывали, что там 700 хранимок в бд

постгрес вообще говнище

ну это наше говнище что у нас на повестке конкурирует? MSSQL?

мои консерны не канают

Скул сервер скоро и на линуксе