Требуется задача сборки CCNET? Несколько репозиториев, по одному исходному разделу CCNET на проект

#asp.net #git #continuous-integration #sitecore #ccnet-config

#asp.net #git #непрерывная интеграция #sitecore #ccnet-config

Вопрос:

Вопросы CCNET — Вот сценарий:

  • У меня есть 10 разработчиков, выполняющих локальную разработку для установки Sitecore с GIT в качестве контроля версий. После завершения работы с их функцией / исправлением они отправляются в репозиторий интеграции.
  • У меня есть настройка CCNET для проекта Sitecore, которая указывает на представителя удаленной интеграции и локальную базу кода live qa. CCNET находит коммиты, которые мои разработчики внесли в репозиторий интеграции, а затем обновляет репозиторий базы кода qa.
  • У меня также есть пара других .Проекты библиотеки Net class, управляемые CCNET, скомпилированные с выводом, указывающим на каталог Sitecore bin.
  • Установка Sitecore является просто результатом сборки без компилируемых аспектов. Это веб-продукт с собственным API, а также возможностью интеграции пользовательских DLL, которые мы создаем для настройки продукта.

Вопросы:

  1. Требуется ли задача сборки CCNET в качестве условия для выполнения других действий, таких как NUnit или robocopy? (я спрашиваю об этом потому, что «сборка» изначально используется для компиляции приложения и генерации выходных данных, тогда как единственная причина, по которой мы хотели бы выполнить сборку, — убедиться, что все зависимости присутствуют, и мы можем перейти к модульному тестированию …).

  2. Если мои разработчики НЕ указывают на централизованную интеграцию, подобную представительству, как CCNET узнает, где находятся все их удаленные репозитории GIT, если документ конфигурации разрешает только один раздел управления исходным кодом GIT для каждого проекта?

  3. Для каждого проекта, когда я настраиваю спецификации GIT vc, запрашивается ветвь, которую необходимо статически сохранить в документе. Есть ли у CCNET возможность динамически принимать разные ветви?

Ответ №1:

  1. В вашем проекте нет необходимости иметь «фактическую сборку» — она может состоять из задач любого типа внутри tasks элемента. У меня есть пара проектов, которые копируют файлы из репозитория на FTP-сервер только после удаления некоторых файлов, которые не должны публиковаться.

  2. У меня нет опыта работы с GIT, но у вас есть возможность определить несколько блоков управления исходным кодом любого типа, если вы используете блок управления несколькими исходными кодами.

  3. Вы могли бы использовать динамические параметры, которые позволяют пользователю устанавливать их значения при запуске сборки.