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