Ветвление ада, где риск и производительность?

Question

Моя компания плавает за идею расширения наших номеров версий еще одной отметкой (например, от major.minor.servicepack до major.minor.servicepack.customerfix), чтобы разрешить конкретные исправления для клиента.

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

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

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

Answer 1

Невозможно помочь в литературе, но разветвление, специфичное для клиента - Плохая идея. Был там, сделал это. Отладка этого материала была чистым адом, потому что, конечно, вы должны были использовать все эти версии для пользователей , чтобы воспроизвести ошибку ... некоторое время спустя компании пришлось сделать полный переписывание приложения, потому что код основа стала совершенно неподъемной. (Перемещение частей, относящихся к клиенту, в файлы конфигурации, чтобы каждый клиент находился на одной и той же кодовой строке.)

Не ходите туда.

Answer 2

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

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

Логика диктует, что для ограничения расходов на поддержку (которые являются огромными, зачастую хуже, чем их развитие) разумная организация предпочла бы иметь наименьшее количество «уникальных» версий, работающих в полевых условиях. Было бы замечательно, однако в реальном мире, как правило, довольно много. Это проблема затрат и удобства.

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

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

Answer 3

Я согласен с тем, что накладные расходы, связанные с исправлениями клиентов, высоки, но я бы не сказал, что не делайте этого.

Я бы сказал, поручив клиенту руку и ногу (и некоторые из них), если они захотят этого внимания. В противном случае не выполняйте филиалы клиентов.

Answer 4

Опишите изменения, которые входят в ветку клиента как «исправления». Поскольку они являются исправлениями, я предполагаю, что они также будут сделаны в багажнике и на самом деле являются просто расширенными поставками будущих исправлений ошибок. Если это так, почему бы просто не создать новый «служебный пакет» (из вопроса: major.minor.servicepack) и предоставить эту версию клиенту.

1. Например, вы выпускаете версию 1.2.3.
2. Заказчик № 1 нуждается в исправлении, создайте версию 1.2.4 и передайте ее Заказчику №1.
3. Заказчик № 2 нуждается в исправлении, коробке версии 1.2.5, передайте ее Заказчику №2 и сообщите, что они также получают временное исправление «бесплатно».

Answer 5

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

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

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

Answer 6

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

Что-то вроде этого лучше всего сделать с помощью настройки профиля/конфигурации/роли.

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

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

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

Делитесь тем, что вы делаете!

Answer 7

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

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

Если ветка «Cisco» подняла дефект, и мы исправим ее, следует ли распространять исправление на текущую версию ветки «IBM» или только на следующую версию ветки «IBM»? Что, если IBM подняла тот же самый дефект?Что делать, если IBM даже не использует функцию, содержащую дефект? Что делать, если IBM позже повышает тот же самый дефект, что и высокий приоритет? С несколькими ветвями филиалов правила распространения никогда не просты, поэтому они в значительной степени гарантируют ветвление ада.