Архитектура нашего решения и совета

Question

В моей организации есть .NET-решение (C# MVC), и мы немного пытаемся сохранить наше решение повторно используемым, но в то же время расширяемым.

У нас есть 4 клиентов

A, B, C, D

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

Это работало около 7 месяцев относительно хорошо, до сих пор.

Клиенты A и B были развернуты и на производстве.

В настоящее время мы работаем над клиентом C, а клиент D еще не реализован.

При работе с клиентом C клиентам A и B также требуются исправления ошибок/изменения функций и т. Д. Однако, поскольку мы работаем с клиентом C, шаблон не всегда «готов к производству», и поэтому код будет выпущен для клиентов A и B с непроверенным кодом. Мы теперь используем большинство функций непосредственно в клиенте C, чтобы не вносить изменения в шаблон.

Конечно, простой вариант заключается в ветвлении и работе с веткой, но поскольку мы вынуждены использовать TFS, это затрудняет задачу. Скорее всего, мы просто будем работать и работать оттуда, но есть ли дополнительные советы (источники информации), чтобы узнать о том, как другие исправляют эту проблему?

Answer 1

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

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

• branch1
  • Решение
    • Проект 1
    • Проект 2
• branch2
  • Решение
    • Проект 1
    • Проект 2

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

• базовые компоненты корневой папки
  • Базовые компоненты ветви
    • Решение
      • Проекты
• Base компоненты Binary Output (возможно, в общей области управления версиями)
• клиентов Решения корневой папки
  • Branch 1
    • Базовые компоненты папки (ответвляется из базовых компонентов двоичный выход, слияние, если вы хотите использовать новую версию компонентов для клиента)
    • Решение
      • Проекты
  • Branch ...

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