Один большой релиз или несколько маленьких?

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

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

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

Что лучше?


release release-management
person Jonathan Sayce    schedule 13.05.2009    source источник

Ответы (7)


arrow_upward
3
arrow_downward

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

person sharptooth    schedule 13.05.2009

arrow_upward
2
arrow_downward

Это действительно зависит от среды, в которой вы находитесь. Некоторые сценарии:

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

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

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

Обычно я делаю 1-2 больших релиза в год и исправляю ошибки в промежутках между шоу-стопами.

person Ralph M. Rickenbach    schedule 13.05.2009

arrow_upward
2
arrow_downward

Я думаю, что лучший ответ: смесь двух.

Например, если вы добавили немного конфет, или сделали текстовое поле имени более «ajaxy», или, может быть, добавили новый тип отчета - сделайте это как «маленькие» релизы. Выпускайте раньше и выпускайте как можно чаще.

С другой стороны, если вы изменили процесс, ориентированный на пользователя, вынуждая пользователей «переобучаться», ИЛИ если вам требуются серьезные изменения инфраструктуры - выбирайте большой выпуск и делайте это как можно реже.

Как вы сказали, если сбоев мало или нет, делайте это как можно чаще, ваши пользователи будут счастливее - И вы фактически будете тратить МЕНЬШЕ времени на регрессионное тестирование, потому что вам нужно только протестировать все, что связано с изменениями. ты сделал.

person AviD    schedule 13.05.2009

arrow_upward
1
arrow_downward

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

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

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

person Jim    schedule 13.05.2009

arrow_upward
1
arrow_downward

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

Лучше небольшие высококачественные релизы. Меньшие выпуски облегчают получение высокого качества.

person John Saunders    schedule 13.05.2009
comment
Это верно в том случае (к сожалению, распространенном), когда тестирование проводится конечными потребителями. К счастью, самолеты так не разрабатывают ;-) - person Joonas Pulakka; 13.05.2009

arrow_upward
1
arrow_downward

Лично я предпочитаю большие релизы.

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

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

person Lieven Keersmaekers    schedule 13.05.2009
comment
@Lieven: казалось бы, решением вашей проблемы было бы создание автообновления, а не меньшее количество выпусков. - person John Saunders; 13.05.2009
comment
@ Джон Сондер: я тебя слышу. Позвольте мне повторить, сказав, что я предпочитаю автоматическое обновление исправлений безопасности и ручное обновление новых функций. Периодичность ручных обновлений (уведомлений) должна быть не менее одной недели. - person Lieven Keersmaekers; 13.05.2009

arrow_upward
0
arrow_downward

Фактически - оба.
Можно ли разделить разработку на ветки DEVEL и RELEASE? Любые срочные проблемы должны быть решены как можно скорее в ветке REL и отправлены пользователям в виде исправления. После применения исправления к ветке REL, необходимость применения патча будет отправлена ​​команде разработчиков (примечание: чтобы исправить некоторую проблему на REL, вам нужно написать некоторый быстрый код, в то время как в ветке DEV вам нужно потратить некоторое время на переосмысление предлагаемого исправления. , поскольку условия в ветке DEV могли измениться, поэтому обычно вы пишете совершенно другой код, чтобы исправить ту же проблему в ветке DEV или REL).
Когда будет завершена разработка новой версии, вам нужно будет протестировать новые функции и исправления, перенесенные из REL. Если все в порядке, вы сможете развернуть новую большую версию и заархивировать текущий DEV в REL, в то время как старый REL будет заблокирован.

person smok1    schedule 13.05.2009