Должен ли бродячий проект быть его собственным репо

Question

Так что я работал с Vagrant, и я нахожу это превосходным, но мне интересно, как это лучше или чаще всего его использовать

Я полагаю, что есть два способа его использовать: первый - создать некое мастер-репо, содержащее информацию о Vagrant и кукольные сценарии для среды разработки для этой организации. Это будет иметь то преимущество, что может быть несколько репо, которые используют его обычным способом.

Второе - создать файл vagrantfile для каждого проекта, который отражает этот конкретный проект.

Второе похоже на то, как я бы пытался структурировать вещи, но мне интересно, есть ли подводные камни с таким подходом.

Answer 1

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

Для меня? Мне нравятся вещи в шаблонах: код, жизнь, бюджеты, списки покупок, сковородки и т.д. Я инженер, и мне нравятся абстрактные и обобщенные вещи, которые можно использовать повторно и расширять. Так что для vagrant я бы хотел одно первичное репозиторий проекта vagrant с инструментом обеспечения, который я предпочитаю (марионетка). У меня были бы разные версии этого абстрагированного и обобщенного, как я считаю нужным для каждого проекта. Если бы моя компания создала сотни сайтов WordPress, я бы сделал установку по умолчанию, которая запускает сервер и устанавливает последнюю (или x) версию WordPress, и аналогичную для любых других проектов, которые не являются раритетами (Symfony, RoR, Laravel). узел).

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

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

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

Во всяком случае, это моя идея о том, как я планирую сделать это, если я когда-либо обойти это.