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

Question

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

Здравствуйте,

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

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

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

Я немного озадачен частью «Проект». Документация гласит

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Еще один вариант межпроектной визуализации - включить Analytics Extension * 1034.* и подключите его к PowerBI .

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