Интеграция нескольких частей проекта в один репозиторий GIT

Question

У меня есть несколько вопросов, и вот сценарий:

• У меня есть один большой веб-сайт Sitecore CMS (Proj A), на котором есть множество как собственных, так и пользовательских dll, которые мы создали для улучшения функций сайта.

• Пользовательские dll генерируются отдельными проектами VS (Proj B, C & D), которые мы вручную компилируем, а затем перемещаем готовый продукт (dll) в каталог bin Proj A.

• В настоящее время у нас есть репозитории Proj A для PROD, Integration, Public, а также каждый разработчик обычно клонирует копию PROD для работы функций / исправлений.

• Proj B, C & D еще не настроены под управление версиями, потому что мы не нашли способа легко интегрировать его релиз в Proj A. Используя рабочий процесс менеджера интеграции, мы позволяем всем делать свои функции / исправления, а затем объединяем их с репозиторием интеграции. На данный момент мы готовы сделать следующее:

  1. Перекомпилировать Proj B, C и D
  2. Robocopy выпускает файлы из каждого проекта в папку Proj A bin
  3. Перекомпилируйте / соберите Proj A и разверните на сервере интеграции.

Вопросы:

1. Вы бы включили Proj B, C и D в структуру каталогов Proj A? Если да, то при компиляции каждого проекта вы бы сделали каталог выпуска для каждого проекта каталогом Proj A Bin?

2. Как / когда вы автоматизируете включение "dll" Proj B, C и D в каталог bin Proj A.

3. Можете ли вы порекомендовать способ оптимизации интеграции этих файлов?

ПРИМЕЧАНИЕ: я исследовал Reps внутри Reps, а также подмодули, но не уверен, что мне нужен только гибрид обоих.

Любые рекомендации будут с благодарностью. Спасибо и приятного вечера. foxtrotzulu

Answer 1

У нас похожая ситуация с веб-приложением ASP.NET, которое зависит от других проектов.

Наше решение состояло в том, чтобы создать веб-приложение и каждую зависимость как отдельное решение VS в отдельном репозитории, затемопределите репозитории для B, C, D как субмодули в репозитории для A.

Решение VS для A включает в себя копии проектов B, C и D, предоставленных субмодулями, и эти проектыявляются ссылками проекта в проекте для A.

Это решает 1 и 2, потому что вы можете просто построить проект A обычным способом, а B, C и D будут автоматически собраны из исходного кода, а библиотеки DLL скопированы вкаталог сборки для A.

Answer 2

Не знаю, помогает ли это кому-нибудь, но просто хотел ответить на мои вопросы:

Вопросы:

Вы бы включили Proj B, C и D в структуру каталогов Proj A? Если да, то при компиляции каждого проекта вы бы сделали каталог выпуска для каждого проекта каталогом Proj A Bin?

Мы решили сохранить proj A (Sitecore web) в качестве отдельного репозитория внутри папки Sitecore rCS. Эта папка содержит репозитории и папку DLL: DLLs dev1_PUBLIC dev2_PUBLIC dev3_PUBLIC INTEGRATION_STAGING PRODUCTION_STAGING

1. Чтобы запустить функцию / исправить все разработчики, установите ванильный Sitecore и выполните PULL для обновления там локального мастера из PRODUCTION_STAGING
2. Оформить локальную ветвь функции, назвав ее в соответствии с заявкой / проектом. Запустите локальный updateDll.bat, чтобы выгрузить обновленные dll.
3. Работать, часто совершать, проверять и проверять
4. PUSH местный мастер
5. Нажмите на "xxxx_PUBLIC".
6. Свяжитесь с менеджером по интеграции, чтобы он / она мог ВЫТЯНУТЬ из общего доступа в INTEGRATION_STAGING.
7. IM тянет к Integration (QA), запускает локальный updateDll.bat, уведомляет dev, чтобы продолжить и тестирует интеграцию с Sitecore или другим проектом
8. Если проверка подтверждена, IM запланирует PULL на PRODUCTION и запустит локальное обновление DLL, bat. Если производство в порядке, IM будет откатывать изменения обратно к PRODUCTION_STAGING, чтобы новая копия была готова.

Мы решили, что proj B, C и D (компоненты C #) имеют свой собственный репозиторий для каждого проекта в папке dotNetProjects. Каждая папка проекта содержит несколько репозиториев: dev1_PUBLIC dev2_PUBLIC dev3_PUBLIC INTEGRATION_STAGING PRODUCTION_STAGING

1. Чтобы запустить функцию / исправить все разработчики, клонируйте копию PRODUCTION_STAGING на локальный компьютер.
2. Оформить локальную ветку функций, назвав ее согласно заявке / проекту.
3. Убедитесь, что выходная папка для проекта указывает на папку "libells" в проектах dotNetProjects. Работайте, часто совершайте коммиты, тестируйте, проверяйте и создавайте проект. проверьте dll дату и время.
4. PUSH местный мастер
5. Нажмите на "xxxx_PUBLIC".
6. Свяжитесь с менеджером по интеграции, чтобы он / она мог ВЫТЯНУТЬ из общего доступа в INTEGRATION_STAGING.
7. IM тянет к Integration (QA), запускает локальный updateDll.bat, уведомляет dev, чтобы продолжить и тестирует интеграцию с Sitecore или другим проектом
8. Если проверка подтверждена, IM запланирует PULL на PRODUCTION и запустит локальное обновление DLL, bat. Если производство в порядке, IM будет откатывать изменения обратно к PRODUCTION_STAGING, чтобы новая копия была готова.

Как / когда вы автоматизируете включение "dll" Proj B, C и D в каталог bin Proj A? Папка вывода для каждого проекта установлена ​​в папку dotNetProjects / releasells, которая не является репозиторием, а просто папкой для размещения dll, связанной с SItecore. Разработчики, добавляющие функции / исправления в sitecore, должны запускать updateDll.bat локально, чтобы получить новейшую версию dll. Вот простой скрипт:

xcopy /E /Y "\\servername\dotNetProjects\ReleaseDlls\*.dll" C:\development\sitecore\WebSite\bin

ПРИМЕЧАНИЕ:

• Шаги 4-8 идентичны выше, редактор давал мне головную боль, поэтому я только что вышел из резервирования.

• Принимая во внимание все dll, что касается Sitecore, мы все еще хотели gitignore dll, потому что это может быть головной болью для наших бизнес-пользователей. Таким образом, чтобы сохранить dll как игнорируемый файл, наш обходной путь - это быстрое решение, описанное выше. Это не то, что мы хотели бы, но если это работает для вас, используйте его, если нет, игнорируйте.

Answer 3

1. Если вы создаете решение, вы можете добавить свой веб-сайт / веб-проект и другие ваши проекты в это решение. если вы затем добавите ссылки с веб-сайта / веб-проекта в эти «пользовательские библиотеки DLL», библиотеки DLL должны быть скопированы (по умолчанию, в противном случае есть опция для этого iirc).

2. Я бы автоматизировал их, если бы они были специфичны для Proj A, если бы это были такие вещи, как внутренние API, утилиты и т. Д., Которые используются во всех проектах, я бы не включил их в решение Proj A. *

3. Не уверен, что я бы порекомендовал этот способ, но если у вас есть собственные библиотеки DLL, созданные где-то автоматически (с помощью CruiseBuild или тому подобное), а затем зафиксированные в хранилище, вы можете добавить внешнее «обновление». Но это также может быть проблемой, если новые изменения будут часто ломать Proj A.

Это ни в коем случае не полное предложение, но, возможно, частичный ответ на ваш вопрос.