Как я могу эффективно управлять кодом нашего продукта для нескольких клиентов с отдельными настройками для каждого клиента?

Question

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

Продукт А продается клиенту 1 и клиенту 2, например. Таким образом, каждый клиент запрашивает свои собственные настройки. Эти настройки должны храниться отдельно от функций основного потока. Однако новые функции основного потока должны быть включены в каждую из копий клиентов при сохранении их собственных настроек.

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

Мы только начали использовать SVN для управления нашим C#.net кодом.

Мой вопрос: из чьего-либо опыта, как лучше всего управлять кодом для всех этих требований при одновременном сокращении дублирования усилий:

1. Основные функции продукта для всех клиентов.
2. Разделяйте настройки каждого клиента и сохраняйте их для клиента в течение всего срока службы клиентского продукта.

Ветвление может решить часть проблемы, однако функции основного потока не будут включены в версии клиентов.

Я надеюсь, что этот вопрос достаточно ясен, и, пожалуйста, объясните ваше предложение как можно яснее с примерами. Спасибо

Answer 1

Вы можете использовать

• Модульная конструкция (ядро + набор модулей) и конечный продукт для клиента будут представлять собой комбинацию (изменяемый набор) модулей, легко управляемую с помощью внешних компонентов в репозитории (каждая настройка создает новую ветвь модуля восходящего потока): это сочетание "веток поставщиков" + внешность
• Монолитный унифицированный код, в котором настройки каждого клиента, собранные в некоторые конфиги (которые вы создаете автоматически на этапе выпуска | сборки), и изменения (на основе этих конфигов) применяются к общему коду только на стороне клиента
• Сочетание предыдущих методов - хранить изменения каждого клиента в отдельной ветке, синхронизировать ветки с основной разработкой (фиктивный путь, требовать строгой политики слияния и точности, может потребоваться много работы по рефакторингу интеграции merge /google "Merge Hell", "Big Bang Merge"/ - но работают без сбоев на стадии поддержки изменений в середине жизненного цикла)

---

Лично я предпочитаю Способ 1 - в этом случае я знаю каждую секунду, какой продукт есть у каждого клиента (и не восстанавливал его по истории) и как этот продукт развивался в течение всего жизненного цикла.

Answer 2

В моей компании такая же ситуация. Наше решение:

• В Свн у нас есть структура

  trunk - основные ветви версий продукта - актуальные версии клиентов и будущие ветви новых основных версий

  • клиент 1 (v1, v2 и т. д.)
  • клиент 2 (v1, v2 и т. д.)
  • теги веток основной версии - релиз для основной версии продукта и тегов клиента

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

У нас около 6 разных версий клиента. На самом деле мы производим слияние вручную, но вскоре мы хотим сделать пакеты, чтобы автоматизировать этот процесс.

Answer 3

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

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