Каков реалистичный способ обработки специфичных для клиента патчей программного обеспечения?

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

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

Наша стратегия ветвления такая (на основе Руководства по ветвлению TFS в Visual Studio , хотя мы используем для этого Subversion)

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

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

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

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

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

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

Короче. Долгосрочные исправить это технически, Краткосрочные сделки с этим.

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

Мы также используем Subversion - и мы сталкиваемся с таким сценарием.

Вот некоторые ключевые моменты, которые следует помнить:

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

2. Специфичные для клиента ветки должны происходить из новой версии. Предположим, у вас есть версия 1.2, а затем вы получили версию 1.2.1 до 1.2.11 - в ветках клиента должны быть разрешены все исправления, поэтому ветка клиента должна оставаться совместимой с основной версией.

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

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

Я попытался соединить эту идею, чтобы показать в :

Как насчет введения механизма расширения в ваш код?

Ваш основной код имеет:

class Foo
{
}

Когда программа запускается, она проверяет DLL / моральный эквивалент, в своей папке запуска для локальных настроек. Если он находит его, он загружается и может содержать специфическую для компании версию Foo

class FooForABC : Foo
{
}

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