А значит сложно потом не продолжать фиксы при мажорных апдейтах

А если у вас есть "основной" сайт и "экспериментальный", на котором вы А/В тесты проводите там, новые фичи пробуете на ограниченном контингенте пользователей - то очевидно что они разрабатываются параллельно и кодобаза временами приводится в более-менее консистентное состояние

Угу. Но это не совсем релизы.

> в этом случае, мне бы пришло в голову выложить стейбл релиз в прод, тут уже видно расхождение в трактовании термина

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

Ну в данном случае это не "тестинг" в стандартном понимании, он тоже стабилен с точки зрения кода, но содержит какой-то функционал, о котором нельзя сказать однозначно, нужен он или нет с точки зрения бизнеса

Так вот у нас так. У девелоперов есть возможность сделать препрод и пустить туда малый процент людей

Угу. Но это не совсем релизы.

ну да, что есть релиз - отдельный вопрос

и в каждой команде трактовка может быть разной

может стоит понимать под релизом то что в прод ушло

У нас во-первых релиз нумеруется не по кодерски, а по номеру тикета с которого он начинается. То есть у нас есть релиз 6749 и есть релиз 6701

По сути это просто сгруппированные задачи

а, ну у вас вообще свой воркфлоу

У нас релизы нумеруются хэшами гита, с которого они побилжены.

И когда мы начинаем сразу делать 2 релиза, то я считаю что просто название неправильное

У нас релизы нумеруются хэшами гита, с которого они побилжены.

у нас есть релиз 2.35 например, и есть app.version для конкретного микросервиса, на основе хэша коммита

у нас есть релиз 2.35 например, и есть app.version для конкретного микросервиса, на основе хэша коммита

мы просто сейчас пытаемся уйти от понятия "релиз". В сторону single-service deployments. Микросервисы, которые деплоятся независимо друг от друга.

В моем понимании релиз это некий shared state проекта

вот примерно этим я сейчас и занимаюсь XD

у меня тут кодеры тупят в дженкинс

как в ролике про шотландецв в лифте с голосовым управлением )

В моем понимании релиз это некий shared state проекта

Ну в моем случае этот "релиз" меняется по 5 раз на день.

Так как релиз - это суммарные тикеты, которые мы разработали за единицу времени

this

как в ролике про шотландецв в лифте с голосовым управлением )

илевен!!!!11111oneeleven

То есть какие тикеты мы бы ни делали всю неделю - все это один релиз на самом деле - то что будет задеплоено на прод

Ну тут путаница в терминах начинается. Слово "релиз" имеет два значения: 1) Условно говоря, git tag - метка, что определенное состояние проекта является цельным и полностью функциональным 2) Процесс выкатки проекта на бой При этом между двумя релизами-выкатками может быть несколько релизов-тэгов, в зависимости от флоу в организации

Это если релизы-выкатки вообще есть

Роллинг-релиз в компаниях тоже встречается

да, тоже верно

Обновили пакет, выкатили в стейдж, работает — пошел в прод

/stat

combot.org/chat/-1001057069601

Не выкатывают прям кусками большими

Обновили пакет, выкатили в стейдж, работает — пошел в прод

Да пошел ты в прод! :D

Так вот у нас так. У девелоперов есть возможность сделать препрод и пустить туда малый процент людей

Это часто зовется демо :)

это называется canary release :)

или так, да

Вообще я почитал разговор. В разных компаниях свой воркфлоу и часто свое понимание терминов.

Где-то stage и test в одном, demo по-разному понимают, где-то релизят прям продукт целиком, где-то патчи тестируют и катят в продакшн небольшими кусками постоянно

Мне кстати очень нравится этот подход. Если stage заапрувлен на данный момент, то просто обновляем до того же состояния прод.

И неважно, один там пакет обновился или 28

Ну что значит хорошо

Конкретизируйте вопрос!

Вообще такой сторадж, который что-то ТЕРЯЕТ из-за пинга в 50мс это пиздец и выкинуть

Если его вообще юзают, такого не должно быть

А гластер кто-то всерьез использует?

Он, по моему опыту, при малейших проблемах в сети начинает капризничать

А гластер кто-то всерьез использует?

тут есть один не заслуживающий доверия товарищ, утверждающий, что используют массово.

В итоге куча времени уходит на его поддержку

вот кстати чтоб прям терял не было

А вот брики пересинкать приходилось иногда

Там еще очень веселая штука с записью прямо в брик. Если такое случилось, то АВАРИЯ АВАРИЯ. Но такого просто не нужно допускать.

Но вообще да, отвратительный опыт работы с ним.

Внутренний садист предлагает NFS :D

Но это не решение, надо над ним писать

(собственно гластер над nfs работает)

Вопрос: нужна ли моментальная синхронизация

Если нет, то вариантов тонна

Причем лаже если да, то inotify и rsync на коленке

Вопрос: нужна ли моментальная синхронизация

дефайн моментальная :) s3 например обещает всегда read-after-write, но допускает read-after-deletion

Допустимо ли, что объект не всегда синхронно доступен с любой ноды.

Ну то есть даже так: нужно распределенное хранилище или просто синхронизация данных.

Потому что это серьезно разные юзкейсы, которые друг с другом путают

по крону, угу

Вообще я гонял тучу данных по syncthing (миллионы файлов), ничего не терялось :3

Так что наверное, если синкать просто, то можно его попробовать

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

ну и да, у меня тестбенч — пачка машин в разных дц именно

Это не тестбенч специально, просто личная инфраструктура

Но так вышло, что это hetzner, Москва и DO

lsyncd есть, если нужно готовое.

если тебе нужно обязательно, чтобы не было read-after-delete или read-stale, то тебе фактически нужно CP-хранилище.

consistency + partitioning

https://ru.wikipedia.org/wiki/Теорема_CAP

так разная реализация совсем

если цеф OSD раскидать по всему миру, тоже хуйня получится

если цеф OSD раскидать по всему миру, тоже хуйня получится

ну работать-то оно будет...

ну работать-то оно будет...

главное туда ничего не копировать? )

да нет, даже копировать можно. но медленно.

Проблема в том, что gluster еще и развалится скорее всего

Будет лежать на спине и ныть

@vdrandom вот ты должен помнить веселье с гластером кстати