многопродуктовая архитектура, с большой общей частью - PullRequest
Новая
       14

многопродуктовая архитектура, с большой общей частью

0 голосов
/ 28 мая 2018

моя компания разрабатывает один «основной» продукт - веб-приложение, в котором пользователи:

  • загружают файлы
  • загружают отчеты на основе этих файлов

Все это делается с помощью базы данных Postgresql, бэкэнда Python3 и внешнего интерфейса Angular / CSS / HTML, разделенных на несколько контейнеров Docker.

Проблема в том, что у нас мало разных продуктов (в настоящее время их 3, но ожидается, чторастут), на долю которых приходится около 95-99% кода, но есть некоторые важные различия, специфичные для продукта.Такими различиями могут быть:

  • другой набор доступных отчетов
  • другой набор принятых типов входных файлов
  • различные учетные записи пользователей (например, подход к "я забыл свой пароль""request)
  • Возможно, намного, намного больше

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

  1. Никогда не объединяющие ветви git.У нас были бы ветви "base", "product_x", "product_y" и т. Д., Общая разработка была бы сделана в "base" (объединена далее во все ветви product_ *), разработка для конкретного продукта была бы сделана в ветвях product_ *.
  2. Каталоги для конкретных продуктов + умное построение.Простейшим решением было бы «код для продукта X - это все в базовой директории, перезаписанное всеми соответствующими файлами в директории product_x»
  3. Полностью отдельные репозитории, при необходимости код будет скопирован из «базовой» репо в репозиторий продукта.
  4. (+ несколько более или менее глупых опций).

У каждого решения, которое мы могли придумать, есть серьезные недостатки.Итак, вопросы:

  • как бы вы это сделали?
  • что нам гуглить / читать, чтобы принять лучшее решение?

Мысознавая, что, вероятно, не существует идеального и безболезненного решения, мы ищем решение, которое не станет ужасно болезненным через год или два:)

...