Моменты назад Джефф Этвуд сказал следующее на twitter:
Посмотрите, я люблю быстрые новые версии программного обеспечения, но частота выпусков WordPress просто смешна.
Что заставляет меня думать, , как часто вы должны выпускать обновления программного обеспечения?
Какая лучшая стратегия выпуска?
Я бы сказал, что в конкретном случае WordPress они объединяют "обновления безопасности" и "обновления функций" . Это плохо.
Это будет похоже на необходимость повторной установки Windows на месте при каждом обнаружении ошибки безопасности вместо простой загрузки небольшого патча каждую неделю.
WordPress должен иметь механизм исправления безопасности, простой, быстрый и простой для обновлений безопасности. Процесс, который отделен от обычного потока обновления новых версий.
Частота выпусков Wordpress настолько частая, что они заботятся о безопасности и выпусках обновлений, которые исправляют известные уязвимости настолько быстро, насколько это возможно. Функциональные обновления Wordpress происходят гораздо реже, в пределах каждых 4-6 месяцев, которые я думаю.
Я думаю, что это хорошая модель. Держите своих клиентов счастливыми, регулярно публикуя новые функции, но если вы обнаружите недостатки в безопасности, немедленно отпустите исправления.
Я предлагаю следующее:
updateTime (в секундах) - среднее время, необходимое пользователю для выполнения обновления
releaseDelta (в днях) - минимальное время между релизами
releaseDelta = updateTime/((1/365)*(60*60*8))
Эта формула основана на моей теории, согласно которой пользователю нужно потратить не более 8 часов в любой заданный год, ожидая обновления приложения.
Это также позволяет частое обновление до тех пор, пока обновления выполняются прозрачным образом, не прерывая конечного пользователя.
Я думаю, это сильно зависит от вашей конкретной ситуации. При этом я считаю, что ежедневный выпуск для любого серьезного бизнес-приложения просто совершенно смехотворный. Если вы выпускаете каждый день, то, вероятно, существует серьезная проблема, если вы не находитесь в какой-то очень странной ситуации, когда бизнес-правила постоянно меняются или что-то в этом роде.
Реже, чем обновления iTunes.
Я пытаюсь использовать следующую, надеюсь, простую, двухчастную директиву:
Итак, для нас такие вещи, как настольные приложения или веб-службы, обычно подпадают под первое правило, и такие вещи, как наш веб-сайт, будут подпадать под второй. Мы проводим довольно хорошие итерации - примерно от четырех до шести недель времени разработки в настоящее время, сокращаясь до двух-четырех в следующем году. Это было наше "введение" в гибрид Scrum.
Обратите внимание, что продукт не всегда должен находиться в разработке (или участвовать в итерации). Вполне возможно, что продукт будет сидеть, устаревший, пока не потребуются изменения, если применяется первое правило.
Это зависит от подхода клиентов к управлению конфигурацией.
У них есть выбор, вы знаете. В конечном итоге они могут не использовать ваш продукт.
Если клиент будет принимать вас каждый день, меняя материал, и им все равно, и он не имеет никакого влияния на обучение или управление конфигурацией; имеют автоматические обновления.
Клиенты с SOE (стандартные операционные среды) ненавидят обновления.
Поймите, что некоторые клиенты не собираются принимать программное обеспечение, "вызывающее домой". Они захотят разместить свои собственные обновления. Их ИТ-специалисты должны будут принять участие. Это больше для них.
Некоторые клиенты захотят/должны выполнить свой собственный QA; зависит от клиента и вида программного обеспечения.
Если клиенту необходимо выполнить тестирование/работу для принятия/развертывания программного обеспечения, отпустите несколько кратных длительности цикла тестирования/развертывания. Если клиенты не в порядке с чередованием развертывания и тестирования. Это то, где они всегда тестируют новую версию и откатывают ее.
Например: 2 недели для тестирования, выпускайте не более чем каждые 8 недель.
В критически важном программном обеспечении выпускное тестирование может занять несколько месяцев. Они делают ставку на результаты и оправданно осторожны. Таким образом, выпускаются каждые 6 месяцев или около того.
В критическом для безопасности программ может потребоваться много месяцев. Ежегодно, или примерно каждые 18 месяцев, не редкость. Еще реже это нормально.
Нет правильного ответа, это действительно зависит от продукта.
Я говорю ежемесячно максимум. Еженедельно/Ежедневно слишком часто, если, конечно, обновления приложений не выполняются автоматическим и прозрачным способом, например. Система обновления Firefox
Вы можете выпускать их так часто, как хотите. То, что расстраивает пользователей, не знает, нужна ли им новая версия или нет. Это означает, что вам нужно четко указать, какие новые функции вы внедрили, исправления, которые вы исправили, и были ли исправлены какие-либо проблемы с безопасностью. Что еще более важно, ваши пользователи хотят иметь возможность доверять тому, что если они устанавливают новую версию, ничего не сломается.
Я думаю, что если возможно , вам следует автоматически обновлять ваше программное обеспечение, когда это необходимо, чтобы сохранить весь процесс обновления как плавный и невидимый для пользователя насколько это возможно.
В области, в которой я работаю, Industrial control, очень редко. Обычно мы делаем основной релиз очень 2 года. Малые релизы, возможно, каждые 3-6 месяцев. Исправление ошибок - это, конечно, другая история, они выпускаются по мере необходимости. Даже тогда немногие клиенты будут модернизировать существующие системы. Конечно, в других доменах обновления более приемлемы.
Конечно, когда у вас есть новые функции/исправления ошибок, которые стоит выпускать? Почему у вас есть график?
У меня нет никаких возражений по устранению ошибок безопасности, как только они будут найдены, хотя я бы хотел, чтобы они писали более надежный код. То, что я возражаю (по крайней мере, до Wordpress), - это усовершенствованные версии, которые могут привести к поломке подключаемых модулей слишком быстро. Сколько времени прошло с 2,5 до 2,6? И 2.7 выходит очень скоро.
Автоматическое или полуавтоматическое обновление смягчит некоторые из этих проблем, но только при обновлении плагинов или если они отделяют исправления безопасности от изменений функциональности, поэтому я могу, скажем, придерживаться 2.5, но все же быть в курсе последних событий с патчами безопасности, пока я не был уверен, что все плагины, которые я использую, работают с 2.6 или 2.7 или (к тому времени) 4.0.
Всякий раз, когда они требуются. Имейте в виду, что некоторые пользователи чувствуют себя более уверенно, регулярно получая обновления, в то время как некоторые просто раздражаются, когда появляются всплывающие окна каждый день. "Есть 129 новых обновлений для установки! Нажмите здесь, чтобы подождать 20 минут, а затем еще 10, чтобы установить их!"... вы видите мою мысль.
Это зависит от характера обновления и количества вмешательства пользователя, необходимого для его выполнения.
Если это веб-сайт, вы можете обновлять его каждый день, пока вы ничего не сломаете.
Если это бесплатное обновление для системы безопасности, ASAP всегда оценивается.
Обновление бесплатного обновления исправлений, если оно должно быть установлено пользователем, должно быть не больше, чем каждые пару месяцев.
Все, что должно быть оплачено, не может быть более частым, чем раз в год, или люди начнут ощущать преимущество. Еще больше для определенных классов программного обеспечения, таких как операционные системы.