Почему бы не развернуться в пятницу? [закрыто]


95

Джоэл упомянул в подкасте № 24 StackOverflow, что политика компании FogCreek не предусматривает поставки программного обеспечения по пятницам. Однако он не уточнил, почему.

Согласен. У моего работодателя мы работаем по четвергам. Итак, у нас есть пятница, чтобы устранить все ошибки, которые не попали в систему контроля качества (QA).

Однако мой менеджер предложил развернуть программу по вечерам в пятницу на тот случай, если у QA не будет достаточно времени для тестирования программного обеспечения перед выпуском. Я говорю: а как насчет планов людей на выходные? А если мы развернемся в пятницу вечером, то в субботу нам придется работать над устранением всех пропущенных ошибок - а это отстой.

Так почему бы не отправить программное обеспечение в пятницу?

* Мы можем (не уверены) сделать это предположение: есть одна основная группа разработчиков программного обеспечения, расположенная в одном часовом поясе, развертывающая основное веб-приложение своей компании.


11
если бы это был мой процесс, он был бы развернут по средам, в середине недели у вас есть пара дней для решения проблем до выходных
CVertex

3
Apple обычно развертывается по вторникам.
mouviciel

2
Во вторник хорошо то, что у вас есть понедельник для окончательных проверок и, возможно, практического развертывания, чтобы все были на одной странице, и у вас есть остальная часть недели, чтобы разобраться со всем, что произойдет. К пятнице вы узнаете, нужно ли вам работать в эти выходные.
Майк Дезимоун

7
Я не понимаю, как это не связано с программированием. Разве развёртывание кода не является конечным результатом программирования?
womp

1
@womp Если я следую вашим рассуждениям, то развертывание кода в конечном итоге связано с достижением некоторых бизнес-ориентированных потребностей. И это должно оправдать любой вопрос, связанный с бизнесом?
Паскаль Тивент,

Ответы:


88

Дело не только в ошибках. Могут быть и другие связанные с этим проблемы поддержки - объяснение пользователям новых функций, наблюдение за отсутствием проблем с производительностью.

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


6
Джон Скит выпускает код в любое время, когда ему нравится, .. верно ?!
Мэтт

16
@Matt - Если день начался как пятница, он перестает быть таким, когда Джон выпускает свое программное обеспечение, Джон Скит не адаптирует свой график выпуска к календарю ... календарь подстраивается под его график выпуска.
Newtopian

2
@Newtopian: вы перепутали это с Чаком Норрисом, Джон Скит - просто бот Google
Niteriter

5
@Matt, исправление: Джон Скит никогда не компилирует код в конфигурации Debug, только Release. Когда компилятор готов, новая сборка немедленно отправляется клиентам по всему миру. Ему это нравится.

2
У моей студии, кажется, ужасная привычка начинать работу в пятницу. Я могу с уверенностью сказать, что мой босс получает большинство звонков от своих недовольных клиентов в субботу / воскресенье, когда что-то упускается. (НИКОГДА НЕ
ЗАПУСКАЙТЕ В ПЯТНИЦУ

51

Никогда не развертывайте в пятницу, потому что:

  1. Это конец недели, поэтому люди менее проницательны
  2. Конец недели, поэтому люди недоступны для исправления ошибок
  3. Сейчас конец недели, поэтому люди не могут отвечать на вопросы
  4. Конец недели, зачем тогда развертывать?

1
КМИС - лучше не скажешь. ..
R Claven

46

Вы в значительной степени ответили на свой вопрос. Это короткая и приятная причина: если вы отправляете товар в пятницу, и ошибка попадает в производство, обычно некому исправить ее или поговорить с покупателями до следующего понедельника. В худшем случае это потенциально несколько дней упущенной выгоды.


1
Тоже самое. Я разрабатываю внутреннее программное обеспечение для производственной компании, поэтому у меня нет внешних заказчиков. Но наши пользователи работают по выходным и в ночные смены, поэтому развертывание в пятницу вечером было бы худшим, что мы могли бы сделать :-)
Кристиан Шпехт,

8

Мы избегаем выпуска кода в четверг или пятницу - никто не хочет тратить пятницу на выяснение критически важных ошибок, и есть вероятность, что даже если мы произведем исправление за 1 день, до его выпуска пройдет как минимум еще один день, что означает либо работу в выходные, либо ремонт не будет до следующей недели.


6

Это зависит от вашей целевой группы. В основном мы отправляемся по пятницам. Наш продукт на основе браузера используется клиентами во всем мире, но в основном в рабочее время. Это означает, что у нас на самом деле нет другого времени, кроме воскресного утра, если мы хотим убедиться, что мы не затрагиваем клиентов (Индия и Ближний Восток не прекращают работу по субботам), но обычно мы идем на «компромисс» и разверните в пятницу после обеда.

Если раньше работали на сайте знакомств, где в идеале мы хотели бы разместить новые вещи примерно во вторник, поскольку пик активности приходился на выходные и, как ни странно, в понедельник около обеда.

Во всяком случае, это сводится к 2 соображениям. 1. Когда это будет наименее разрушительным для ваших клиентов (если это веб-приложение) и 2. Когда оно будет лучше всего согласовано с командой разработчиков для быстрого исправления критических ошибок.

Если вы беспокоитесь о том, что ваши разработчики станут небрежными к концу недели, ваш конвейер контроля качества может быть слишком коротким.


5

Вы должны развернуть его в пятницу, чтобы у вас были все выходные, чтобы очистить его и исправить ошибки, прежде чем остальная часть вашей команды заметит ваши упущения в понедельник.


4

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

К этому люди склонны быть немного более небрежными по пятницам (уже думая о том горячем свидании | холодном пиве | и том и другом) и за несколько дней до отъезда в отпуск ;-)


4

Это действительно зависит от вашего приложения и от того, насколько оно загружено / критично в выходные.

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

Это действительно зависит от того, пытаетесь ли вы свести к минимуму влияние любого простоя, необходимого для выпуска вашего релиза, ИЛИ уменьшить возможные ошибки.

Вы не увидите никаких ошибок до тех пор, пока клиенты не начнут использовать систему (в большинстве случаев), поэтому развертывание в пятницу эквивалентно развертыванию в понедельник утром, если у вас низкая загрузка в выходные.

С другой стороны, такие вещи, как интернет-магазины, как правило, чаще используются по выходным, поэтому вам определенно не рекомендуется развертывать один из них в пятницу.

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

Обычно мы развертываем вещи со вторника по четверг, предпочитая избегать понедельника (наш самый загруженный день) и выходных (когда ошибка может оставаться незамеченной, вызывая проблемы)


3

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

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


2

Я работал с компанией, у которой была политика развертывания по пятницам; они были в Израиле, и суббота обычно последний день рабочей недели. Тем не мение...

В моей последней компании политика заключалась в том, чтобы предоставить Ops пакет развертывания не позднее обеда по вторникам и четвергам. Это означает, что у них есть полдня, чтобы разобраться с этим и запросить незначительные корректировки, если что-то пойдет не так с последним этапом предварительного тестирования. (Любое другое QA может произойти в любое время недели, потому что оно не в прямом эфире.)

Выпустить в любую среду, кроме живого, можно в любое время, если у Ops есть время для этого (конечно, это все равно должно быть забронировано заранее), но никогда не выпускайте, чтобы жить дальше:

Понедельник - Плохо, вы только что вернулись с выходных (надеюсь, нерабочих) и не будете думать обо всем, что делали на прошлой неделе. Среда - обычно наименее продуктивный день недели и считается «серединой рабочего» дня. Если ваш слот был во вторник, и вы пропустили его из-за ошибок, среда, вероятно, будет плохим выбором, поскольку у вас недостаточно времени, чтобы исправить и проверить эти ошибки. Пятница - Давай. Шутки в сторону? Это пятница. Если это действительно требует объяснения, значит, у вас недостаточно опыта, чтобы занимать ту управленческую должность, на которой вы занимаетесь. А если серьезно, это потому, что развертывание по пятницам означает, что ваши клиенты будут добровольно приходить на выходных, чтобы проверить вашу работу вживую. Окружающая среда. Для меня это лучше любого идиотизма, за который вы, возможно, выстраиваете себя.


1
Я согласен, что доставка по пятницам плохая. Я хотел, чтобы сообщество StackOverflow дало мне веские причины, чтобы я мог легко убедить своего менеджера отказаться от любой возможности развертывания в пятницу. И, надеюсь, эта ветка поможет другим разработчикам программного обеспечения, таким как я, избежать ужасных пятничных развертываний :)
Билл Паецке

0

Нам посчастливилось хорошо использовать разницу во времени, у нас есть офисы по всему миру. Таким образом, делая обновления для клиентов, мы организуем их так, чтобы они делались для клиента в одночасье, чтобы минимизировать влияние на них.

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

  1. Поддержка причуд и ошибок, которые могут возникнуть
  2. Поддержка пользователей при переходе
  3. Горячие исправления в последнюю минуту
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.