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

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

Я согласен. У моего работодателя мы развертываем в четверг вечером. Таким образом, у нас есть пятница, чтобы очистить любые ошибки, которые пропустили Quality Assurance (QA).

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

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

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

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

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

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

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

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

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

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

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

Ответ 9

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

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

Ответ 10

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

Ответ 11

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

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

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