Laravel 5 многоразового использования

После непростой сборки пакета для проекта, мы поняли, что есть некоторые проблемы с выполнением того, что нам нужно для достижения в соответствии с Laravel 5 ясность разработки пакета

Может быть, я лучше объясню свою цель, и кто-то может подсказать, куда идти.

Мы создали приложение Laravel 5, которое теперь нужно «повторно использовать».

Нам пришлось модифицировать Laravel и реализовать базовую модель типов Eloquent, поскольку нашим источником данных на самом деле являются веб-службы C #. В тот момент, когда будет сделан вызов в базу данных, мы перехватываем это и делаем «API» вызов SOAP.

Основное различие будет CSS, может быть, некоторые JS & содержание, но все маршруты / контроллеры / модели останутся одинаковыми во всех проектах. Большая часть конфигурации происходит от конечных точек.

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

Затем мы начали экспериментировать с идеей создания «ядра» как пакета Laravel, но, похоже, мы постоянно сталкиваемся со стенами. Последняя проблема — включение моделей в комплект. Для вызова моделей мы используем корневой проект config / composer для доступа к этим моделям, а не только к поставщику услуг. Такое ощущение, что пакет становится тесно связанным с конфигурацией проекта.

Есть ли лучшие способы добиться того, чего мы пытаемся достичь?

Редактировать:

Я забыл о решении с несколькими филиалами на 1 репо, но разве это не будет уродливым, когда дело доходит до разработки функций? Пример:

master (core with releases that get pulled into _site*)
dev (master dev)
feedback-form (eg. master branch feature)
_site1 (root site with releases)
_site1-dev (_site1 dev)
_site1-reskin (eg. _site1 feature)
_site2 (root site with releases)
_site3 (root site with releases)

Это оставляет довольно много разрушительной силы слияния в руках разработчиков? Доступ на чтение с помощью запросов извлечения может быть решением этой проблемы?

1

Решение

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

Кажется, немного неуклюжий, но, вероятно, «самый чистый» вариант.

0

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]