Использовать конвейер непрерывной интеграции VSTS с проектами из разных репозиториев Git - PullRequest
0 голосов
/ 26 августа 2018

У меня есть эта особая установка, которую я хотел бы включить в VSTS и непрерывную интеграцию + непрерывное развертывание.Для простоты я сведу мою ситуацию к следующей настройке:

У меня есть два решения, A и B, которые находятся в отдельных репозиториях Git.Один проект A1 решения A ссылается на проект B1 решения B. Поскольку это упрощенный случай для демонстрационных целей, давайте предположим, что репозитории Git не могут быть объединены!

Сейчас я настраиваю CIдля проекта А1.Очевидно, что сборка проекта не удалась, поскольку не удается разрешить зависимости от B1.

До сих пор я нашел два решения для моего дела, которые оба меня расстроили:

  • Вариант 1) Все ссылки, которые не могут быть разрешены NuGet, должны быть добавлены в папку библиотеки, см. Как правильно проверять DLL / сборки в TFS / Visual Studio Team Services (была VSO) Я мог бы согласиться с этим вариантом в тех случаях, когда это зависимости от третьих сторон, которые редко меняются, например, два раза в год.Однако, так как я сам компилирую B1 (и я мог бы делать это часто), мне не нравится это решение.Конечно, я мог бы автоматически копировать двоичные файлы из B1 в A1 / lib после сборки B1, но я хотел бы избежать проверки в двоичных файлах B1.
  • Вариант 2) Использовать NuGet длякаждая ссылка, которую я хочу интегрировать.Я знаю, что могу настроить свой собственный локальный сервер NuGet.Я не уверен насчет решений для хостинга с «закрытыми пакетами».Использование Nuget для этого кажется излишним, так как я разрабатываю A1 и B1 локально, и для каждой локальной сборки B1 мне нужно было выдвинуть новую версию и обновить пакеты из A1, прежде чем обновления будут переданы в A1.Прямо сейчас я могу собрать B1 локально, и A1 сразу же увидит обновления.Давайте предположим, что у меня много локальных сборок для разработки, по сути, я не хочу выдвигать 50 + / 100 + сборок для B1 каждый день.

Я также настрою конвейер CI для B1 вVSTS.

Полагаю, я ищу способ использования "ссылочного пути" для VSTS для поиска зависимостей, которые я строю из другого конвейера CI.Есть ли какое-то общее пространство для мусора для проектов VSTS?Перед сборкой A1 я автоматически скопировал бы собранный двоичный файл из B1 в A1.

Есть ли какой-нибудь хороший способ добиться этого?В данный момент я думаю о решении для отправки / предварительной сборки FTP / облака после / перед сборкой, но, учитывая мою ситуацию (зависимости от разных Git-репозиториев), должно быть довольно распространенным, какое решение?

1 Ответ

0 голосов
/ 27 августа 2018

Если вы не хотите управлять projectB1 пакетом NuGet, есть другие опции, которые вы можете использовать.

Предположим, что solutionB управляется в repoB, а структура файла в repoB.например:

repoB
  |___solutionB
           |___projectB1
                    |___...
           |___...
  |___...

Вариант 1: клонировать репоВ во время сборки напрямую

В начале определения сборки вы можете добавить задачу PowerShell к клонированию репо.Сценарий PowerShell, как показано ниже:

# If you are using private agent to build and clean source is false, you should check if the repoB folder exist or not
git clone https://Personal%20Access%20Token:{PAT}@{account}.visualstudio.com/{project}/_git/repoB

Чтобы убедиться, что solutionB сначала собрана, вы можете использовать две задачи сборки VS.Первый используется для сборки solutionB (repoB/*.sln), а второй - для сборки solutionA (**/solutionA.sln).

Вариант 2: добавить repoB в качестве подмодуля для repoA

Если вы хотите добавить repoB в качестве подмодуля для repoA, то вы можете добавить repoB в качестве подмодуля для repoA с помощью:

git submodule add https://{account}.visualstudio.com/{project}/_git/repoB

Затем зафиксируйте и отправьте изменения на удаленный repoA.

Примечание: вам также нужно сначала добавить еще одну задачу VS Build для построения решенияB.

Вариант 3: добавить ветку repoB (например, главную ветвь)как поддерево для repoA

Подобно субмодулю, вы можете добавить ветку (например, master) repoB в repoA с помощью:

git subtree add --prefix=repoB https://{account}.visualstudio.com/{project}/_git/repoB master
...