Azure DevOps - организация проектов и репозиториев

Question

(Размещая здесь вопрос, так как это "сообщество", на которое Microsoft перенаправляет кнопку "Нужен совет? Спросить сообщество". Надеюсь, оно не будет закрыто как "в основном основанное на мнении" или "слишком широкое")

Привет,

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

Некоторые из этих приложений имеют очень короткий жизненный цикл, то есть мы поставляем их, и они работают годами без изменений. Другие приложения больше по размеру и обновляются / исправляются в течение нескольких месяцев или лет.
Эти приложения полностью отделены друг от друга во всех аспектах.

Насколько я понимаю структуру DevOps Azure, мой отдел должен стать "Организацией" (мы можем / должны быть отделены от остальной части корпорации).

Я немного озадачен частью проекта. Документация говорит

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

Итак, скажем, у нас есть один проект под названием Our Apps - куда мы тогда помещаем все индивидуальные заявки-проекты?

Насколько я понимаю, каждый продукт (приложение), который мы поставляем, должен иметь свой собственный репозиторий (или набор приложений, если они логически связаны).

Это сделано для того, чтобы позволить разработчику просто клонировать репо на своем компьютере и вносить свой вклад только в этот продукт - без загрузки других проектов и т. Д.

Мне нужно уметь:

• легко перемещаться / видеть все десятки /(сотни?) приложений, которые мы создаем,
• просмотреть их отдельные доски канбан (для тех проектов, у которых они есть, не у всех)
• чтобы увидеть их репозитории (Git или TFS), коммиты и т. д.
• видеть и управлять своими трубопроводами

На данный момент мне кажется, что единственное место, где я могу увидеть "список" того, что у нас есть, это выпадающее меню ниже:

И единственный способ увидеть, что происходит в продуктах "достаточно большой, чтобы получить собственную плату", - это создать новую отдельную "Команду SomeApp" в Проекте (хотя в ней участвуют одни и те же люди), так что я может иметь доску для SomeApp - и просмотрите доски отсюда:

1. Это намеченный способ организовать структуру?
2. Какие-нибудь альтернативные подходы?
3. Есть ли какой-нибудь способ получить обзор "кросс-хранилища" или "кросс-команды"?
4. А как насчет создания документации для каждого "продукта"?

Answer 1

" Один проект, чтобы управлять ими всеми" был придуман Мартином Хиншелвудом и его постом в блоге с давних времен, когда объясняются причины и ограничения.

С введением тегов и фильтрации в бэклоге появился альтернативный подход в рамках одного проекта.

• Создайте команду для реальных команд, которые есть в вашей организации.
• Создайте путь области для каждого крупного проекта / продукта в организации.
• Назначьте области направлений проектов, над которыми работают эти команды. Это может измениться со временем.
• При желании пометьте рабочие элементы основным проектом / продуктом для дополнительной фильтрации.

Таким образом, каждая команда видит полный обзор всей работы, которую они могут выполнить. И они могут быстро фильтровать работу по тегам, чтобы убрать элементы из поля зрения при обсуждении конкретных проектов / продуктов.

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

Расширение Plan View обеспечивает дополнительный межгрупповой обзор всей работы. А расширение Dependency Tracker может визуализировать зависимости с течением времени.

Вы также можете использовать древовидную структуру Epic/Feature/PBI|UserStory для создания дополнительной группировки в ваших рабочих элементах. Вы можете настроить шаблон процесса для представления уровня продукта, хотя для работы функций планирования это также будет означать, что вам также потребуется создать полную прослеживаемость от продукта до PBI|UserStory.

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

Другой вариант для межпроектной визуализации - включить расширение Analytics и подключить его к PowerBI.

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

Answer 2

Спрашиваю здесь, потому что моя ситуация похожа на описанную @Bartosz. У нас есть сотни репозиториев в TFS, организованных в каталоги и подкаталоги. Мы планируем перенести все это в Azure Devops, используя конвейеры для CI и, возможно, Artifacts. На данный момент мы не заинтересованы в получении рабочих заданий или советов. Мы просто пытаемся организовать, управлять и просматривать репозитории, чтобы, например, мы могли

1. Управляйте доступом к этим репозиториям.
   • добавление разработчика в группу, дающее им доступ к git clone к большинству репозиториев, но не git push
   • добавление разработчика в небольшую группу, которая предоставит git push доступ к репозиториям определенной команды,
   • добавление разработчика в очень маленькую группу, которая даст им доступ к суперсекретному репо
2. Принесите более тонны унаследованного кода в заархивированном состоянии. Таким образом, это не видно в моем обычном, повседневном опыте репо, но доступно, если мне нужно копать.
3. Просмотрите, отфильтруйте мой взгляд на репо, чтобы увидеть только
   • репо, которые являются частью определенной более крупной системы.
   • репозитории, которые представляют собой API-решения, веб-интерфейсы или мобильные решения и т. д.
   • репозитории, зависящие от X, где X может быть.dll, API, определенной базы данных и т. д.

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

Я нашел эту ветку, где, похоже, другие борются с такой же потребностью: https://developercommunity.visualstudio.com/content/idea/365451/allow-organizinggrouping-git-repositories-in-a-tea.html

И я нашел это расширение, которое может помочь с некоторыми из них https://marketplace.visualstudio.com/items?itemName=ms.vss-code-search

Есть ли рекомендуемый способ для крупных организаций с большим количеством репозиториев кода перейти на DevOps Azure?