VSTS терминология и структура

Question

Впервые в VSTS, но не в Git. У нашей небольшой команды есть обычное сочетание веб-приложений, приложений для Windows, других приложений / служб разного назначения, и мы также храним объекты нашей базы данных в проектах Visual Studio SQL Server. Таким образом, существует около 15-20 различных наборов кода для работы. В настоящее время у каждого будет свое Git-репо.

Читал этот пост, касающийся одного или нескольких "Командных проектов". Затем я опубликовал это ранее, но это было специфично для элементов отставания, но я полагаю, что мой реальный вопрос был о более широкой картине относительно идеи "командного проекта"

Какая будет хорошая структура для небольшой команды с таким количеством заявок. Предполагается, что каждое приложение обычно работает независимо, но вы можете собрать два или более этих приложений вместе.

Как насчет одного командного проекта. Несколько «команд», по одной на «приложение». Это терминология, которая сбивает меня с толку.

Могут ли разные команды использовать разные репо?
Может ли каждая команда иметь свой набор определений? например. dev / prod и т. д.

Answer 1

Как вы настраиваете свою структуру, действительно зависит. Есть много способов организовать это. Один репо, несколько репо.

Если вы используете сборки CI, помните, что задача get sources в вашей сборке загрузит ваше полное репо. Так что если у вас есть одна стратегия репо, ваша сборка может занять больше времени. В этом сценарии у вас также будет больше работы по настройке сборок и указанию фильтров пути, которые будут запускать только правильную сборку в процессе CI.

Могут ли разные команды использовать разные репо?

Да, могут.

Вы можете создать группу безопасности для каждой команды.

Затем в вашей команде вы можете удалить его из Contributos и добавить свою новую группу в состав Member:

После этого в настройках контроля версий добавьте новую группу безопасности и удалите или запретите доступ к группе безопасности Contributos. Таким образом, только ваша группа безопасности команды будет иметь доступ к репо.

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

Может ли каждая команда иметь свой набор определений сборок? например. DEV / прод и т.д.

Вы можете настроить сборку для каждого из ваших репозиториев. Если вам необходимо определить, кто имеет доступ, вы можете сделать это, изменив безопасность каждой сборки, удалив материалы и добавив свою группу безопасности.

Answer 2

Командный проект - это контейнер для портфеля связанных приложений. Командный проект может содержать одно или несколько репозиториев с исходным кодом (Git / TFVC), сборок, выпусков, тестовых примеров, рабочих элементов и т. Д. Все эти объекты имеют способы определения безопасности вокруг того, кто может просматривать / изменять их.

Команда - это просто организационная структура внутри командного проекта. Вы можете использовать разрешения безопасности, чтобы ограничить определенные репозитории, сборки (или сборки папок) и т. Д. Для определенной группы.

Общепринятое руководство - хранить все в одном командном проекте. Есть много вещей, которые не пересекают границы командных проектов, таких как репозитории. Обходные пути обычно существуют, но они обычно неуклюжи.

Одно требование, которое вы дали ( [мы] могли бы захотеть собрать 2 или более этих приложений вместе ), на самом деле немного сложно, независимо от того, находятся ли репозитории в одном или в нескольких командных проектах - определение сборки можно подключить к одному репо. Если вам нужно ввести дополнительные репо, вам нужно будет использовать субмодули или добавить дополнительный шаг сборки для клонирования второго репо. Я почти гарантирую, что будет проще, если все будет в одном командном проекте.

Одним словом, ответ на два прямых вопроса, которые вы задали, - «Да».