Как структурировать репо для поддержки поддоменов Netlify?
Поддомены Netlify работают на основе веток репо. Если у меня есть домен, например xyz.com, а репо Repo-A, основная ветвь будет развернута на xyz.com, а ветка dashboard развернется на dashboard.xyz.com. Однако панель управления и основная ветвь сильно различаются, за исключением нескольких визуальных элементов.
Я пытаюсь найти четкий способ структурировать репо
Repo - A
(master branch)
src/app
package.json
webpack.config.js
Repo - A
(dashboard branch)
src/app
package.json
webpack.config.js
Проблема с этим подходом в том, что мне пришлось бы сильно менять файлы webpack, package и src.
Я считаю, что переключение между ветвями также приведет к появлению большого количества мусора в папке dist/.
Какая структура репо лучше всего подходит для этого? Существуют ли инструменты, упрощающие жизнь для этого варианта использования?
Другой подход -
Create a Release Repo that has release branches like master and dashboard.
master commits to Repo A which pushes build to master branch of Release repo
master commits to Repo B which pushes build to dashboard branch of Release repo
Это более чистый подход по сравнению с первым? Какие-либо предложения?
Ответы 1
Эта функция больше подходит для постановки / разработки / производства (основной), когда вы используете их для отслеживания изменений для проверки и выполнения запросов на вытягивание для каждой ветви поддомена через рабочий процесс. Я не использую эту функцию, потому что рабочий процесс легко отследить, создав развертывание филиала в любом случае. Я думаю, это действительно пригодится при отслеживании версий моего сайта на поддоменах для разных версий.
При использовании субдомена для совершенно другого проекта вам следует подумать о перемещении их в их собственные репозитории и управлении проектом как собственным сайтом в субдомене. Затем введите запись субдомена CNAME в DNS, чтобы указать на my-dashboard-site-name.netlify.com
Моно-репо
Вы могли бы иметь их в одном монорепо, если вы не хотите делать их своим собственным репо, вы все равно будете разделять развертывание сайтов. Это немного сложнее, чем их собственный репозиторий, но такие инструменты, как Lerna, есть, если вы хотите поддерживать его таким образом. Это отличный способ поддерживать проекты, которые повторно используют одни и те же библиотеки, которые не публикуются в диспетчере пакетов, а в том же монорепозитории.