так что node.js и django вполне актуальны, хоть это Чистякову не нравится

При этом Чистяков напропалую используеть простите Хадуп и СмартОС. И не любит Java и nodejs. Т.е. он знает цену своей нелюбви :)

Бикоз май инглиш из тэррибл

Ноубади кэрз ивн иф ю ар э дог

который навяжет мерила всего - рынок

Рынок навязывает Wordpress

так что node.js и django вполне актуальны, хоть это Чистякову не нравится

Я патчил Node.JS, если что

Сишный код, я имею в виду

если кто-то использует, и платит деньги, значит так нужно

Платит деньги? За джанго? Ох каман

Да, так вот

Я могу себе позволить плавать против рынка

Алекс, пиши на ноде

будь мужиком

80% веб разрабов знают js

если кто-то использует, и платит деньги, значит так нужно

Кто тт использует кобол

И кому то за это платят

Давайте все поэтому учить кобол

Всем все платится

Тут актуальнее вопрос "что не учить"

Угу. И не очень. Понятно зачем девопсу нода

Не очень понятно, зачем вообще нода

Давайте будем исходить из того, что я не девапс

Давайте заодно пойдем на соседний девопс канал, чтоб срачи там разводить, а тут только по делу

но на ноде уже столько всего написано. Хорошего и разного

Давайте заодно пойдем на соседний девопс канал, чтоб срачи там разводить, а тут только по делу

Да ну срать я хотел

Это все пчеловодство

но на ноде уже столько всего написано. Хорошего и разного

И что?

npm

?

На перле тоже "было столько всего написано"

вот черт, я только хотел этот аргумент привести

ладно, закапываем. Нода не нужна. Руби еще есть

Ты какой-то неадекват, чел

Ты какой-то неадекват, чел

Щта

У меня девопсовопрос.

Правильно ли я понимаю что по определению невозможно разрабатывать сразу два релиза?

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

почему? Часто параллельно разрабатывают, допустим, 2.1.5 и 3.0.0

Это релизы которые на одной и той же кодовой базе выходят?

Тикеты могут быть багфиксами старого функционала, а могут быть новым функционалом

Ну, изначально да, они идут от одного родителя. Один из релизов LTS, например, который обязались сопровождать еще 5 лет без внесения нового функционала, а второй - движение дальше

Ну а если например сразу параллельно разрабатывать 2 релиза 2.1.5 и 2.1.6 а потом их одновременно задеплоить? ;)

а нахуя?

Вот и я задаюсь тем же вопросом

чо бы все сразу 2.1.6 поставили? )))

нет не так

У нас нету такой нумерации релизов. Клиенты версии не видят вообще.

надо ещё написать так, что бы с 2.1.4 до 2.1.6 без 2.1.5 нельзя было обновиться

вот это благо будет

и чтоб эти версии еше несовместимы были

ага

Мы выпускаем сервис, а не библиотеку или фреймворк

и чтоб эти версии еше несовместимы были

так в чём вопрос то был?

Вопрос был в том, что собой представляет понятие "релиз"

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

> у вас не получится делать два релиза одновременно и тем не менее, ... ?

Мы прямо сейчас это делаем

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

они параллельно несколько релизов пилят

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

Ну в рамках мажорных версий это одно

Мы прямо сейчас это делаем

Просто делая параллельно разные релизы сложно потом будет мержить их

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

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

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

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

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

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

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

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

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

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

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

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

ERROR: S client not available

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

У нас во-первых релиз нумеруется не по кодерски, а по номеру тикета с которого он начинается. То есть у нас есть релиз 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