Что мы используем в Azure Dev: проект или конвейеры для каждого решения

Нужна помощь с лазурными конвейерами. Просто протестировал его и подумал о переходе с 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 и библиотеки классов)

Эти проекты .NET расположены в разных репозиториях git? Является ли ваш инструмент git репозиториями Github или Azure Devops? Лично я использую проекты для разделения разных логических проектов (команд разработчиков) и разных пайплайнов внутри одного проекта для разных проектов команды. Например, у команды А может быть 4 проекта, я бы выбрал один проект DevOps и 4 конвейера внутри него. У команды Б будет отдельный проект

GeralexGR 18.03.2022 09:37

Да все они в разных репозиториях. Даже у каждой библиотеки есть свой репозиторий на github. Я использую Гитхаб. Понятно, что я создам 3 проекта для web1, web2 и wpf, но как насчет общих библиотек?

pantonis 18.03.2022 09:43

С общими библиотеками можно обращаться так же, как и с разными проектами. Вы можете создать их и загрузить через задачу на nuget. Если они должны быть включены в проекты, они уже должны быть в ваших проектах web1, web2 и wpf, в результате конвейер, который будет выполнять восстановление msbuild и nuget, также будет обрабатывать библиотеки.

GeralexGR 18.03.2022 09:55

Да, именно так это работает сейчас в TeamCity. Я создаю их, упаковываю и отправляю в частную ленту nuget. Вопрос в том, добавить ли их все в проект и создать конвейер для каждой библиотеки или создать один проект для каждой библиотеки и внутри каждого проекта создать один конвейер?

pantonis 18.03.2022 09:57

Это должно сильно зависеть от доступа, который вы хотите предоставить (людям). Если вы не хотите исключать некоторые проекты для конкретных людей, я бы выбрал один проект DevOps и разные конвейеры для каждого проекта библиотеки. Обычно вы комбинируете конвейер с репозиторием github. В результате, если все ваши библиотеки размещены в одном репозитории github, вы будете использовать один конвейер, иначе вам придется создать несколько конвейеров внутри одного и того же проекта Azure Devops.

GeralexGR 18.03.2022 10:11

отлично, спасибо. Вы можете написать это как ответ

pantonis 18.03.2022 10:52
docs.microsoft.com/en-us/azure/devops/organizations/projects‌​/… предоставляет несколько хороших примеров плюсов и минусов нескольких проектов по сравнению с командами и способов масштабирования организации Azure DevOps в целом.
danielorn 18.03.2022 14:08
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
7
34
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Написание комментариев в качестве ответа, чтобы мы могли закрыть вопрос.

Эти проекты .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)

Другие вопросы по теме