Comments 29
Надо делать как надо, а как не надо делать - не надо!
Можно еще посоветовать писать код без багов, тогда и вовсе фиксить не придется.
У нас есть тесты, CI/CD, QA и команда дежурных инженеров. Но пятницу, пожалуйста, оставьте без выкатки больших фич. Большая фича - координация десятка человек, оповещие всех соседних команд, запуск рекламы и тому подобное. А люди имеют свойство ошибаться: пропускать баги, покрывать false-positive тестами, забывать про индексы, ревьюер может иметь замыленный глаз, ПМ забыть про важную штучку, которая на глаза попалась именно после релиза.
А откатывать всю эту красоту будет дежурный инженер. Вот оно ему надо?
выкатывать релиз в продакшн в пятницу, будь он даже 100500 раз затестен, не стоит ещё и потому, что у пользователей неизбежно появятся вопросы по новому функционалу, хотя есть инструкции и на обучении всё это говорили. А отвечать на этот вал вопросов будет вынужден дежурный спец поддержки. Основная команда в выходные предпочитает отдыхать.
Вторник, конец рабочего дня. Прибегает шеф и требует задеплоить новую фичу в прод именно сегодня. Совершенно непонятная срочность, так как от отсутствия этой фичи в течение ещё пары недель никто не умрёт.
Я: Только закончил реализацию, ещё не тестил. Давай завтра спокойно всё доделаю?
(Ш)еф: Сколько времени надо чтобы прогнать тесты и задеплоить?
Я: Ну, часа четыре, если исправлять ничего не придется.
Ш: Задержись, надо задеплоить сегодня.
Я: У меня планы на вечер, я уже собирался домой.
Ш: Я тебе такси до дома вызову.
Я: Если настаиваешь - давай задеплоим без тестов. Может сломаться, так что под твою ответственность.
Ш: Делай. (убегает)
Конечно же, утром пришлось всё срочно чинить, был разбор причин инцидента. Зато с деплоями с тех пор больше никто не подгонял :)
Аргументы из статьи бьются одной фразой - shit happens.
К сожалению, но вот оно происходит. Даже когда все процессы казалось бы доведены до идеала (а такого не бывает) оно происходит. Реже, да, но происходит. И люди просто выбирают между маленьким шансом огрести проблем и между 100% шансом их не огрести.
Общий посыл статьи то верный, делайте хорошо, а плохо не делайте, но подводка к нему неудачная. С другой стороны я вот тут и строчку коммент, так что может на то и был расчёт).
Ну и да. Разговор с копипастой - это традиции!
Ваши 3 шага не устраняют 100% багов. А в пятницу не деплоят вовсе не из-за чьих-то фобий, а потому что суббота выходной. Точно так же избегают предпраздничных дат и отпусков критичного персонала. Не нужно подменять риск-менеджмент на психологию.
Ну, если в выходные есть кому подхватить если что, то можно и в пятницу деплоить.
Бывают же компании, в которых нет выходных, а есть смены или индивидуальный график.
Ну допустим мы написали отличный, полностью оттестированный код, всё проверили на 10 раз и за полчаса до окончания рабочего дня отправили в деплой, но что то пошло не так и деплой пошел не по плану, что нибудь случилось и что? Половина SoC и программистов не пошла домой и сидит думает что делать, откатывать релиз в срочном порядке или можно быстро починить, а починить быстро это не факт что качественно. У всех были планы но теперь они должны что? Забить на работу и пойти заниматься своими делами? Или забить на свой отдых и работать дальше? И всё это ради чего? Поэтому и нет деплоя в пятницу, это не от того что ты не уверен в своем коде или проекте, а потому что всегда должен быть запас времени на shit happens...
Выберите правильный язык программирования. Вам не нужны языки, для которых деплой является проблемой. Выберите Delphi - благодаря предкомпилированным юнитам собирайте большие проекты в десятки раз быстрее чем на C++ и перестаньте бояться возможных проблем при сборке.
Это правило написанное кровью.
команда может быть сколь угодно талантливой и ответственной, но человечески фактор на любом этапе никто не отменял - забыл, не учел, даже не подумал....
Мы не деплоим в пятницу
Похоже, автор текста никогда не работал с крупными нагруженными проектами.
Вот сходу статья про пятничный деплой. Как додо пицца прилегла на 4 часа в пятницу вечером.
Всегда это твердил всем вокруг, вот какой-то добрый человек написал нормальную статью.
Если вы боитесь деплоить по пятницам и перед праздниками, то стоит ли вам деплоить вообще, без уверенности что вы (или, лучше, автоматика) вовремя обнаружите и быстро откатите любую проблему?
Не деплоим не из-за не уверенности, а из понимания что если что сломается, должно сломаться когда на рабочем месте есть нужные сотрудники и когда финансовые потери для бизнеса будут минимальные.
Так у вас система может в любой момент сломаться и без деплоев, для этого и есть онколл, не так ли?
А если факт деплоя заметно повышает вероятность сбоя, то, видимо, что-то не так с качеством и/или процессами. В таком случае инженерам будет хороший стимул исправить проблему, чтобы их онколл был спокойнее :)
Деплой по определению увеличивает неопределенность на проде. Зачем самим себе создавать проблемы? Пусть онколл останется для внезапных продакшен проблем, а не для разгребания «А что там в новой версии могло пойти не так?»
Вот этот майндсет «деплой - это проблема» и отравляет мне жизнь уже почти десять лет, не говоря уже обо всей индустрии. Не должен он быть ей, а если есть, то надо это чинить.
Деплой сам по себе это не проблема. Проблема это разбираться что пошло не так и точно ли это неожиданное поведение в пятницу вечером или на выходных.
Последний тест для любого кода это продакшен. Всегда что-то может пойти не так. Люди не идеальны и делают неидеальные вещи. Для защиты от такого поведения используют специальные методики. Как вам постепенная выкатка новой версии в течении двух недель?
Куда эта спешка? Не успели в четверг? Ну и ладно. Поедет в прод в понедельник. От этого никто не умрет. И даже денег потеряно особо не будет. Зато команда нормально отдохнет и будет более счастлива.
Хотфиксов это конечно не касается. Они едут в прод по готовности и по степени важности. Горящий прод до понедельника не оставляем. Я именно про типовой новый релиз.
Есть много вещей, которые можно воспроизвести только на проде. Дело же не только в написанном коде. Код запускается в инфраструктуре под нагрузкой. Вот эти инфраструктуру и нагрузку вы сможете гарантированно протестировать, только если поднимете рядом второй прод и будете дублировать туда запросы. Но так почти никто не делает. Поэтому при деплое на прод у вас всегда есть фактор неизвестности. Правило "не деплоить в пятницу" - это попытка управления этим фактором.
Для тестирования под нагрузкой есть нагрузочное тестирование.
Для тестирования взаимодействия с инфраструктурой и соседними сервисами есть стейджинг, который, в идеале, и должен быть вторым продакшеном по архитектуре и вообще всему, кроме размера.
Деплоить каждый раз как в неизвестность - мне, например, здоровья уже не хватит :)
стейджинг, который, в идеале, и должен быть вторым продакшеном по архитектуре и вообще всему, кроме размера.
В прошлом году была интересная статья от "додо пицца", как они прилегли в пятницу вечером на 4 часа: тыц. Там сложились факторы деплой+нагрузка+рекламные пуши. Ну еще пара косяков в конфигах. В теории, такое можно было бы отловить на стейджинге, если бы:
стейджинг был бы размером, как прод;
на него бы лилась нагрузка, как на прод;
на него бы лились пуши, как на прод;
Деплоить каждый раз как в неизвестность - мне, например, здоровья уже не хватит :)
По большому счету, чем больше изменений, тем больше неизвестность :) Есть же такие вещи, как ошибки, стреляющие через несколько часов. Бывает лавинообразный выход из строя при достижении некоторого порога производительности. А еще бывают плавающие баги, когда проблема возникает не только на проде, но и раз в N времени.
Поэтому на прод и деплоят мягенько, аккуратненько, поглядывая на графики. Подстилают соломки в виде blue/green и канареечных деплоев. А заодно страхуют себя от проблем, воздерживаясь от деплоев по пятницам.
Как говорится: Спасибо, но НЕТ.
В пятницу, даже обновы и патчи не ставлю
Забыли еще, как минимум, несколько шагов:
Внедрение метрик для выявления проблем при/после деплоя
Автоматизация отката релизов (наличие автоматизации деплоя также подразумевается)
Автоматический откат релизов
Я так понимаю, 100% отписавшихся в комментах не поддерживают продвигаемую концепцию "понты сильной команды"? Да потому что практика реально показывает, ибо ну его нафиг на выходных и праздниках устранять последствия принятых имиджевых решений эффективных менеджеров.
Этого мема тут не хватает
Деплоить в пятницу я начну только по принятии иудаизма(с)
Ни в чём нельзя быть уверенным на все 100%. Предположим, что при каждом обновлении есть шанс в N%, что появятся ошибки. Это нормально. Теперь следует посмотреть на пользовательскую активность по дням недели. Как правило, к выходным количество активных клиентов возрастает, а к понедельнику снижается. Это связанно не только с выходными разработчиков, но и, по случайному стечению обстоятельств, с выходными большой массы населения. Если простой в будни обернётся достаточно серьёзными потерями (как финансовыми, так и репутационными), то такой же инцидент в выходные становится просто катастрофой.
Дело не в том, что разработчики должны отдохнуть, хотя и это тоже. Дело в том, что риск того, что все сотрудники будут вне кондиции к моменту аврала очень неиллюзорный ибо пятница традиционно ассоциируется с алкоголем (но не у всех).
Умножаем гипотетические потери в час на шанс найти ответственного специалиста, готового оперативно и на трезвую голову починить всё. Выходит, лучше в пятницу с определённого времени (например, со второй половины дня) воздержаться от обновлений. Даже для тех, у кого смена.
Огонь статья!
Особенно хорошо в пятницу вечером катить обновление, задевающее смежников. Предупредив их конечно утром - мы же не звери - а что у них посыпется что-то мелкое, что не успевают проверить взмыленные ручные тестировщики - ну извините, зато мы успели в эту неделю, йуху!
Всегда есть вероятность косяка, её можно только уменьшить, но не исключить. И встаёт собственно вопрос, а зачем рисковать выходными, если есть, пускай и минимальная, но вероятность. Не деплоить в пятницу - это не неуверенность в продукте, а просто реальный взгляд на вещи.
Внедрите стабильный набор автоматизированных тестов
Не бойтесь деплоить в пятницу