Черт возьми, где риск и производительность переломный момент?

Question

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

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

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

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

Answer 1

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

Не ходи туда.

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

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

Answer 7

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

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

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