Стратегия ветвления для настраиваемого программного обеспечения

Question

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

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

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

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

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

спасибо

1012 * Джефф

Answer 1

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

Answer 2

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

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

Answer 3

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

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

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