Архивирование веб-приложений - Общее решение + независимый экземпляр -> Рост и обслуживание?

Question

В настоящее время я работаю над веб-решением (backend & frontend), который будет доставлен нескольким клиентам. Каждый из них будет размещаться независимо со своей собственной базой данных.

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

Важным моментом является то, что в любом случае приложение/сайт/решение (особенно в интерфейсе) не будут одинаковыми для всех, а некоторые файлы (шаблоны // CSS/...) будут независимыми.

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

Одним из решения я думал о является:

• Создать один базовый проект, который будет содержать все классы, компоненты, общие для всех, и предложить своего рода «рамки».
• Создайте один проект для каждого клиента (одна независимая папка).
• SYMlink все файлы/папки, которые будут поддерживаться глобально (на уровне BASE).

Преимущества:

• Одно изменение базового проекта (новая функция/ошибка исправления ..) будут автоматически доступны везде.
• Мы можем по-прежнему держать определенную «независимость» уровня в коде, так как каждый проект является независимым и файл может быть обновлен (за исключением базы одного)

я не уверен, что лучшим решением будет, и если есть такая «лучшая практика» для таких целей. Просьба поделиться своим опытом по этой теме.

Спасибо!

Answer 1

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

Возможно, вы захотите следовать определенному типу архитектуры. MVC является наиболее популярным, в котором часть, которая обрабатывает взаимодействия с базами данных (M), рендеринг результатов в html (V) и части, выполняющей сложные операции (C), является отдельной.

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

Я, кстати, разработчик Python/Django, и я использую эту комбинацию для создания проектов, которые придерживаются принципа DRY (Dont Repeat Yourself), и что касается ваших потребностей, имеет возможность предоставлять настройки для сайта. Поскольку вы упомянули в основном о различиях в интерфейсе, в качестве примера, это позволит вам указать приложению использовать template1 (html, css) при доступе к www.example1.com и шаблоне2 при доступе к www.example2.com, но все они живут в одном экземпляре проекта.

Надеюсь, что помогло.