Mail.ru Group corporate blog
Programming
Development Management
Build automation
Agile
Comments 17
+1
Этот пользователь считает, что проблемы рискованного деплоя не должно возникать благодаря доступным нам сегодня процессами и инструментам.

А программисты не должны допускать багов. Ожидания и реальность редко соотносятся


Что касается деплоя по пятницам — тут нужно смотреть с точки зрения пользователей. Если пользователям важен деплой именно в пятницу — значит нужно поступать так (и строить свои процессы соответственно). Пример: Path of Exile запускает новые лиги в пятницу вечером, чтобы игроки могли играть все выходные не отвлекаясь на работу


Если пользователям это не нужно — лучше деплоить в понедельник. Пример: Вы делаете какой-то бизнес продукт и ваши пользователи в массе своей пользуются им только в рабочие дни. Какой смысл делать релиз в пятницу, если это не приносит никакой пользы и повышает риски?

0
> Если пользователям важен деплой именно в пятницу — значит нужно поступать так

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

> Пример: Path of Exile запускает новые лиги в пятницу вечером, чтобы игроки могли играть все выходные не отвлекаясь на работу

Как вариант — задеплоить фичу на неделе, протестировать на избранны пользователях в stealth режиме, а в пятницу включить ее для всех с помощью feature toggle.
+1
а в пятницу включить ее для всех с помощью feature toggle.

А если в feature toggle будет ошибка? :)

0
То это вероятно станет известно раньше. Feature toggles нужно тестировать тщательно, и конечно заранее. Но тут в общем такая же история как и с другими багами. Невозможно защититься от обнаружения багов в пятницу. Но можно хотя бы не деплоить новые баги в пятницу.
0
Не увидел критерия критичности системы, только «радиус поражения».
В мире есть много систем, которые спокойно пролежат до понедельника (тотальное поражение).
Похоже, не раскрыты темы «Можно ли развертывать в пятницу 13-го?» и «Можно ли развертывать в субботу (чтобы не прерывать цикл)?»
Вера в инструменты, в номер текущего года и в тесты задорно-заразительная, конечно.
+6
Проблема в том, что даже небольшое, некритичное, косметическое, внесённое в вообще не связанную систему изменение может случайно сломать что то важное.

Забить очередь, вызвать проблему разворачивания, сломать вёрстку, открыть цикл без выхода, сделать удаление объекта с тысячами связей итп-итп.

И сколько от этого не защищайся — оно всегда может вылезти.

Так что, от греха подальше, не надо деплоить в пятницу, если в этом нет особой необходимости (требует бизнес).
+1
Одни коммиты немного правят интерфейс и ничего более;
так я и поверил
+2
Меня, наверное, за такие еретические мысли закидают хабротапками, но всё же:
почему никто не учитывает версию, что обновление продакшна в понедельник опасно для бизнеса чуть более, чем полностью? Почему важнее без эксцессов провести выходные, а потом посреди недели положить прод и чинить его, в то время как сервисы будет недоступны и бизнес будет нести убытки?

Разумеется, бизнес должен оплачивать такие работы, а для этого ИТ должен объяснить, зачем это нужно и почему это важно.

Здоровье, конечно же, важнее всего, и отдыхать нужно всем, но если глобальные сбои и падения войдут в систему, то не́куда будет возвращаться с выходных. Разве не лучше сделать всё в период минимальной нагрузки и вовлечённости пользователей, когда можно спокойно исправить все вылезшие баги, прогнать все тесты, а если что-то упадёт – поднять, опять же без паники и потока тикетов?
+1
Почему важнее без эксцессов провести выходные, а потом посреди недели положить прод и чинить его, в то время как сервисы будет недоступны и бизнес будет нести убытки?
Потому что сама проблема «не деплой перед выходными» — она про то, чтобы не создавать внезапную сверхурочную работу. Если бизнесу сильно критично, он может запланировать обновление на выходные, и тогда никакой проблемы не будет.
0

Мне кажется, что не бизнес должен планировать обновления, а ИТ, исходя из общих целей

0
Проблема в том, что есть много систем, которые должны работать в выходные, а не только посреди недели. Но, если посреди недели люди работают — следят за системой, с клиентской стороны готовы что то исправить, перезалить или ещё как то отреагировать, то в выходные всё это намного менее контролируемо, а потому — должно быть стабильно.

Тут была где то прекрасная история о том как у «админа» отвалилась удалёнка в выходные, когда всё легло, а охрана не пустила в офис, потому что «выходной, не положено». Это как пример нештатного эксцесса в выходной )
0
Не понимаю этих предрассудков. Откладывание деплоя на 3 дня — это 3 дня для юзеров без потенциально пофигшенных багов или новых фич. Если, условно, релизить результаты по результатам двухнедельных скрамов и каждый раз откладывать релиз на 3 дня, то за год у вас будет 52/2*3 = 78 дней пауз в релизах из-за ваших страхов и предрассудков. А у ваших конкурентов — не будет. И они вырвутся вперёд.

Нужно выйти что-то экстренно поднять в субботу? Ну и отлично! Оплата по ставке 2х, такси на работу и назад, дополнительный отгул — и я легко выйду. Тем более, что понадобится это аж 2-3 раза в год. Копеечные затраты для бизнеса. Всех бы проблем.
UFO landed and left these words here
0
Мы решили никогда не деплоить в пятницу. И еще каждый деплой по одной функциональности только, легче откатить, сразу ясно что накрылось и почему. И обязательно CI/DI.
+1
Такая же ситуация, все наши заказчики хотят чтобы код сливался в пятницу, сколько уже ругани и мата было по этому поводу в среде разработчиков. Так что в таких случаях обычно поступаешь так, деплоить в пятницу — не вопрос, но если будут баги, любой овертайм по двойной или тройной ставке, а т.к. обычно без багов не обходится, то потом сидишь до часу ночи. Но вообще двойная-тройная ставка у многих заказчиков отбивает желание релизить в пятницу.
Одно время вообще практиковали релиз каждый день, чтобы парочку фишек каждый день выдавать в прод, это было вообще ужасно, тимлид полдня только и занимался что МР-ами, релизом, и тестами.
Only those users with full accounts are able to leave comments. , please.