Как часто следует выпускать обновления программного обеспечения?[закрыто]

StackOverflow https://stackoverflow.com/questions/360028

  •  21-08-2019
  •  | 
  •  

Вопрос

Несколько минут назад Джефф Этвуд сказал следующее в твиттере::

Слушайте, я люблю быстрые выпуски новых программ, но частота выпусков WordPress просто смешна.

Это заставляет меня думать, как часто следует выпускать обновления программного обеспечения?

  • Ежедневно?
  • Еженедельно?
  • Ежемесячно?
  • Ежегодно?

Какова лучшая стратегия выпуска?

Это было полезно?

Решение

Я бы сказал, что в конкретном случае WordPress: они смешивают «обновления безопасности» и «обновления функциональности»..Это плохо.

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

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

Другие советы

Частота выпусков Wordpress настолько часта, потому что они заботятся о безопасности и выпускают обновления, которые исправляют известные уязвимости как можно быстрее.Обновления функциональности WordPress происходят гораздо реже, я думаю, раз в 4–6 месяцев.

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

Я предложу следующее:

updateTime (в секундах) — среднее время, необходимое пользователю для выполнения обновления.

ReleaseDelta (в днях) — минимальное время между релизами

releaseDelta = updateTime/((1/365)*(60*60*8))

Эта формула основана на моей теории, согласно которой пользователю придется тратить не более 8 часов в год на ожидание обновлений приложения.

Это также позволяет осуществлять частое обновление, при условии, что обновления выполняются прозрачно, не отвлекая конечного пользователя.

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

Реже обновляется, чем iTunes.

Я стараюсь использовать следующее, надеюсь, простое руководство, состоящее из двух частей:

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

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

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

Это зависит от подхода заказчика к управлению конфигурацией.

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

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

Клиенты с SOE (стандартными операционными средами) ненавидят обновления.

Помните, что некоторые клиенты не собираются принимать программное обеспечение «звонок домой».Они захотят размещать свои собственные обновления.Их ИТ-специалистам придется принять участие.Для них это дополнительная работа.

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

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

Например:2 недели на тестирование, выпуск не чаще, чем каждые 8 ​​недель.

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

В критически важном для безопасности программном обеспечении это может занять МНОГИЕ месяцы.Ежегодно или примерно каждые 18 месяцев – не редкость.Даже реже – это вполне нормально.

Правильного ответа нет, это действительно зависит от продукта.

Я говорю максимум ежемесячно.Еженедельно/ежедневно — это слишком часто, если, конечно, обновления приложений не выполняются автоматически и прозрачно, например.Система обновлений Firefox

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

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

Для области, в которой я работаю, промышленное управление, очень редко.Обычно мы делаем крупный релиз в течение двух лет.Незначительные релизы могут происходить каждые 3–6 месяцев.Исправления ошибок — это, конечно, отдельная история, они выпускаются по мере необходимости.Даже в этом случае лишь немногие клиенты будут модернизировать существующие системы.Конечно, в других областях обновления более приемлемы.

Конечно, когда у вас есть новые функции/исправления ошибок, которые стоит выпустить ??Зачем это делать по расписанию?

У меня нет возражений против того, чтобы ошибки безопасности исправлялись сразу же после их обнаружения, хотя мне бы хотелось, чтобы они в первую очередь написали более надежный код.Что я возражаю (по крайней мере, в том, что касается Wordpress), так это выпуски расширений, которые потенциально могут слишком быстро сломать плагины.Сколько времени ушло на переход с 2,5 на 2,6?И 2.7 тоже выйдет очень скоро.

Автоматическое или полуавтоматическое обновление частично смягчит эту проблему, но только в том случае, если авторы плагинов также обновятся или если они отделят исправления безопасности от изменений функциональности, чтобы я мог, скажем, придерживаться версии 2.5, но при этом быть в курсе безопасности. патчи, пока я не был уверен, что все плагины, которые я использую, работают с 2.6 или 2.7 или (к тому времени) 4.0.

Всякий раз, когда они потребуются.Имейте в виду, что некоторые пользователи чувствуют себя более уверенно, получая обновления регулярно, в то время как некоторые просто раздражаются, когда каждый день появляется всплывающее окно «Необходимо установить 129 новых обновлений!»нажмите здесь, чтобы подождать 20 минут для загрузки, затем еще 10, чтобы установить их!"...вы понимаете мою точку зрения.

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

Если это веб-сайт, вы можете обновлять его каждый день, если ничего не сломаете.

Если это бесплатное обновление безопасности, ASAP всегда приветствуется.

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top