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

Question

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

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

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

Как лучше?

Answer 1

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

Answer 5

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

Меньшие, высококачественные выпуски лучше.Меньшие выпуски облегчают достижение высокого качества.

Answer 6

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

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

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

Answer 7

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