🤬 МЫ НЕ РЕЛИЗИМСЯ В ПЯТНИЦУ!!!!

Правило не релизиться в пятницу — это суеверие.

Я убеждён, у сломанных релизов есть объективные причины: плохое тестирование, неучёт рисков, отсутствие плана отката, отсутствие мониторинга, отсутствие нужных людей поблизости, чудовищный техдолг, сбой во внешнем софте или оборудовании.
Мне оппонируют — “Игорь, ты о каких-то космических штуках пишешь, у нас люди говнокод пишут и задачи не успевают закрывать, нам некогда!”. Поэтому, мол, будем писать как можем, а в пятницу релизить — нельзя.

Тем не менее:
Если релизы систематически ломаются и люди закрывают проблемы переработками, то “не релизиться в пятницу” — это не решение, это манипуляция-суеверие, чтобы защититься от бесконтрольных овертаймов.

Закрывшись этим лозунгом вы никак не движетесь к улучшению ситуации.
Релизясь в пятницу, ускоряя развитие продукта, улучшая инфраструктуру по итогам каждой аварии — движетесь. Но только если ваши менеджеры — не мудаки и правильно задают вектор движения команды.

Есть ситуации, в которых релизы в пятницу сомнительны, но они не связаны со страхом потерять выходные, например:
- в пятницу/выходные сложно достучаться до людей, необходимых для решения инцидентов (админы на подряде не работают по выходным; менеджер в выходные на рыбалке и плевал на всё)
- в пятницу/выходные — повышенный трафик и авария принесёт огромные потери (у многих бизнесов есть сезонность: праздники, новый год, 1 сентября, 8 марта и т.п.)

Если же изменение не протестировано, не готово, плана отката нет, но мы всё равно катим его на прод, потому что “надо” — будет больно что в выходные, что в будни, и дело в болевом пороге, а не в замедляющем развитие суеверии.