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

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

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

Я предлагаю следующее:

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

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

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

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

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

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

реже, чем обновления iTunes.

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

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

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

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

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

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

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

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

понимаем, что некоторые клиенты не собираются примите программное обеспечение "calling home". Они захотят разместить свои собственные обновления. Их ИТ-людям придется вмешаться. Это больше Работа для них.

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

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

например: 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, чтобы установить их!"... вы меня понимаете.

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

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

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

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

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