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

16

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

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

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

Ваймс
источник
Если вы использовали hgили gitя мог бы предложить вам использовать очереди исправлений ( расширение Mercurial Queues или Stacked Git ), но я не знаю, есть ли в TFS что-то подобное.
Марк Бут
Может быть, я должен был указать, что мы используем Subversion, хотя мы используем стратегию ветвления, предполагающую использование TFS: P Сократят ли очереди исправлений необходимое тестирование? Похоже, это для патчей контроля версий? Мы имеем дело с исправлениями, которые клиент устанавливает на системы конечных пользователей.
Ваймс
2
Бизнес-решение будет таким: не делай этого.
JeffO
@JeffO хороший вызов =) В любом случае, есть ли способ сделать это управляемым данными переключателем времени выполнения?
Патрик Хьюз
1
@JohnB - Извините, я не знаю, но если у вас есть исправления исходного кода, тогда ваша система сборки должна быть в состоянии автоматизировать тесты, плюс сохранение патчей для каждого клиента за пределами svnозначает, что они не загромождают ваш обычный рабочий процесс. Если очереди исправлений выглядят так, как будто они могут быть полезны, вы можете попробовать их, используя git-svn или hgsubversion . Использование внешнего интерфейса DVCS для сглаживания сложного рабочего процесса svnможет даже побудить людей рассмотреть возможность перехода на оптовую продажу DVCS, чтобы получить все остальные преимущества.
Марк Бут

Ответы:

5

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

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

Чарльз Ламберт
источник
5

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

Лорен Печтель
источник
Это может работать для простых настроек, но более сложные могут сделать продукт более неудобным и нестабильным для всех клиентов.
FrustratedWithFormsDesigner
3
@FrustratedWithFormsDesigner Сложные настройки для отдельных клиентов представляют собой грубую небрежность в управлении и дизайне продукта. Любое решение, для которого требуется отдельный филиал для одного клиента для продукта, представляет собой серьезную неадекватность продукта для удовлетворения всех потребностей клиентов и плохое управление со стороны владельца продукта.
maple_shaft
2
Я также видел этот укус моего предыдущего работодателя снова и снова. Это просто плохая практика, но обычно это то, что руководство хочет и не отступит. В частности, если вы используете Subversion, это просто кошмар, который не уйдет - синхронизация кода будет вредить снова и снова.
Стив Хилл
1
@maple_shaft - Но вы хотели задать вопрос: «Вы когда-нибудь использовали ветвление кода для реализации интернационализации»?
PSR
3
@maple_shaft - я шутил, но на самом деле, это была моя точка зрения, использование ветвления для обработки интернационализации, по крайней мере, так же плохо, как и для веток, ориентированных на клиента Это не спорный вопрос в том смысле , что вы , вероятно , не хотите , чтобы работать в таком месте либо. Это спорный вопрос в том , что я собирался довольно по теме.
PSR
3

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

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

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

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

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

ElGringoGrande
источник
2

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

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

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

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

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

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

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

Дипан Мехта
источник
1

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

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

class Foo
{
}

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

class FooForABC : Foo
{
}

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

Уинстон Эверт
источник