Нужна помощь с лазурными конвейерами. Просто протестировал его и подумал о переходе с TeamCity на Azure Dev, и мне стало интересно:
У меня есть:
1. Asp.Net Core Web Api (Web1)
2. Asp.Net Core Web Api (Web2)
3. WPF App
4. Several infrastructure class libraries that are shared libs between the above 3 solutions (Web1, Web2, WPF).
Создать 4 лазурных проекта?
1 project that includes the repository of Web1 project with 1 pipeline that nuget restores, builds and publish artifacts
1 project that includes the repository of Web1 project with 1 pipeline that nuget restores, builds and publish artifacts
1 project that includes the repository of WPF App with 1 pipeline that nuget restores, builds and publish artifacts
1 project that includes all repositories of all class libs and for each library I create a pipeline
или я создаю один проект для всех и добавляю по одному конвейеру для каждого (web1, web2, приложения wpf и библиотеки классов)
Да все они в разных репозиториях. Даже у каждой библиотеки есть свой репозиторий на github. Я использую Гитхаб. Понятно, что я создам 3 проекта для web1, web2 и wpf, но как насчет общих библиотек?
С общими библиотеками можно обращаться так же, как и с разными проектами. Вы можете создать их и загрузить через задачу на nuget. Если они должны быть включены в проекты, они уже должны быть в ваших проектах web1, web2 и wpf, в результате конвейер, который будет выполнять восстановление msbuild и nuget, также будет обрабатывать библиотеки.
Да, именно так это работает сейчас в TeamCity. Я создаю их, упаковываю и отправляю в частную ленту nuget. Вопрос в том, добавить ли их все в проект и создать конвейер для каждой библиотеки или создать один проект для каждой библиотеки и внутри каждого проекта создать один конвейер?
Это должно сильно зависеть от доступа, который вы хотите предоставить (людям). Если вы не хотите исключать некоторые проекты для конкретных людей, я бы выбрал один проект DevOps и разные конвейеры для каждого проекта библиотеки. Обычно вы комбинируете конвейер с репозиторием github. В результате, если все ваши библиотеки размещены в одном репозитории github, вы будете использовать один конвейер, иначе вам придется создать несколько конвейеров внутри одного и того же проекта Azure Devops.
отлично, спасибо. Вы можете написать это как ответ
Написание комментариев в качестве ответа, чтобы мы могли закрыть вопрос.
Эти проекты .NET расположены в разных репозиториях git? Является ли ваш инструмент git репозиториями Github или Azure Devops?
Лично я использую проекты для разделения разных логических проектов (команд разработчиков) и разных пайплайнов внутри одного проекта для разных проектов команды.
Например, у команды А может быть 4 проекта, я бы выбрал один проект DevOps и 4 конвейера внутри него. У команды Б будет отдельный проект и т. д.
С общими библиотеками можно обращаться так же, как и с разными проектами. Вы можете создать их и загрузить через задачу на nuget. Если они должны быть включены в проекты, они уже должны быть в ваших проектах web1, web2 и wpf, в результате конвейер, который будет выполнять восстановление msbuild и nuget, также будет обрабатывать библиотеки.
Если вы не хотите исключать некоторые проекты для конкретных людей, я бы выбрал проект один DevOps и конвейеры другой для каждого проекта библиотеки.
Обычно вы комбинируете конвейер с репозиторием github. В результате, если все ваши библиотеки размещены в одном репозитории github, вы будете использовать один конвейер, в противном случае вам придется создать несколько конвейеров внутри одного и того же проекта Azure Devops.
В целом подход, который я в основном использую:
Different Azure DevOps projects -> Different dev teams.
Projects inside one dev team -> Different pipelines inside the project.
Different github repositories -> Different pipelines for each one (exceptions apply here but in most cases it is a practice)
Эти проекты .NET расположены в разных репозиториях git? Является ли ваш инструмент git репозиториями Github или Azure Devops? Лично я использую проекты для разделения разных логических проектов (команд разработчиков) и разных пайплайнов внутри одного проекта для разных проектов команды. Например, у команды А может быть 4 проекта, я бы выбрал один проект DevOps и 4 конвейера внутри него. У команды Б будет отдельный проект