Как правильно организовать структуру SPA проекта с учетом удобства контроля версий и деплоя?
Здравствуйте,
требуется организовать проект по разработке одностраничного приложения (SPA), при этом фронтенд должен разрабатываться на одном из популярных js фреймворков, и подразумевается сборка проекта системой сборке на основе gulp/webpack. Бэкенд должен быть реализован на Laravel 5.х.
Итак, есть фронтенд часть, которая на выходе дает сборку js скриптов и используемых ими ресурсов (css, картинки и др.), и эта сборка должна сопрягаться с Laravel бэкендом.
Вопросы:
1) как наиболее корректно весь исходный код проекта версионировать (пусть с помощью git)? Сделать один общий репозиторий или отдельно для бэкенда и фронтенда?
2) как сделать так, чтобы было легко выполнять развертывание проекта (деплой)? По идее, хорошо иметь слепок/версию проекта, содержащую актуальную сборку фронтенд части, актуальный код бэкенда + миграции. Дилемма (лично для меня) тут в том, что для развертывания не нужны исходники фронтенда, только готовая сборка. Сборка постоянно пересобирается сборщиком. Если делать общий репозиторий, то в него будут попадать исходинки фронтенда, которые не нужны на продакшен сервере при деплое. Если делать два разных репозитория для фронтенда и бэкэнда, то как синхронизировать актуальную сборку и соответствующую ей версию бэкэнда, ведь по хорошему это должно быть в одном репозитории.
Надеюсь, что не слишком сумбурно, прошу совета или ссылок на какие-нибудь доки, способствующие просветлению в этом направлении.
разделить лучше на репозитории
например: "project-front-end" и "project-back-end"
можешь создать еще репозиторий просто с именем "project" и сделать два подмодуля на фронт и бэкенд
не знаю как на одиночном развертывание но при масштабирование будет достаточно удобно
А как быть с тем, что мне для бэкенда нужен именно результат работы сборщика фронтенда, а не весь репозиторий с фронтендом. Даже бывает так, что при разработке SPA не нужны html файлы с разметкой, только собранные стили и скрипты. Т.е. в итоге все равно руками нужно брать очередную сборку и копировать ее в нужно место для бэкенда? Или сборщик должен предусматривать такую функциональность как копирование требуемых файлов сборки при каждой пересборке в указанное место с заменой старых?
Владимир Пономарев: сборщик запускаешь и всё, там он уже всё сам соберет, минифицирует и тд
как вариант можешь в релизе делать сборку в папку dist а потом клонировать этот релиз куда надо и сделать чтоб веб морда смотрела на dist
Средний
