Поделиться через

Планирование организационной структуры

  • Статья

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

Рассмотрим следующие структуры для вашей организации и совместной работы в Azure DevOps:

Кроме того, вам может потребоваться запланировать следующие сценарии:

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

Что такое организация?

Организация в Azure DevOps — это механизм для организации и подключения групп связанных проектов. Примерами являются бизнес-подразделения, региональные подразделения или другие корпоративные структуры. Вы можете выбрать одну организацию для всей компании, одну организацию для себя или отдельные организации для конкретных бизнес-подразделений.

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

  • Azure Pipelines: одно размещенное задание с 1800 минут в месяц для CI/CD и одного локального задания
  • Доски Azure: отслеживание рабочих элементов и доски
  • Azure Repos: неограниченное количество частных репозиториев Git
  • Azure Artifacts. Управление пакетами
  • Неограниченные заинтересованные лица
    • Первые пять пользователей бесплатно (базовая лицензия)
    • Azure Pipelines
    • Доски Azure: отслеживание рабочих элементов и доски
    • Azure Repos: неограниченное количество частных репозиториев Git
    • Артефакты Azure: два ГиБ бесплатно для каждой организации

Примечание.

Облачная служба нагрузочного тестирования Azure DevOps устарела, но Нагрузочное тестирование Azure остается доступным. Эта полностью управляемая служба нагрузочного тестирования позволяет создавать масштабную нагрузку с помощью существующих скриптов Apache JMeter. Дополнительные сведения см. в статье "Что такое нагрузочное тестирование Azure" и "Изменения функций нагрузочного теста" в Visual Studio и облачном нагрузочном тестировании в Azure DevOps.

Сколько организаций вам нужно?

Начните с одной организации в Azure DevOps. Затем можно добавить дополнительные организации, которые могут потребовать различные модели безопасности. Для одного репозитория кода или проекта требуется только одна организация. Если у вас есть отдельные команды, которые должны работать над кодом или другими проектами в изоляции, рассмотрите возможность создания отдельных организаций для этих команд. У них будут разные URL-адреса. Добавьте проекты, команды и репозитории при необходимости перед добавлением другой организации.

Пройдите некоторое время, чтобы просмотреть рабочую структуру и различные бизнес-группы и участников, которыми нужно управлять. Дополнительные сведения см. в статье "Сопоставление проектов с бизнес-подразделениями и рекомендациями по структуре".

Совет

Для организаций Microsoft Entra, принадлежащих компании, рекомендуется ограничить пользователей созданием новых организаций в качестве способа защиты IP-адреса. Дополнительные сведения см. в разделе "Ограничить создание организации с помощью политики клиента Microsoft Entra". Пользователи могут создавать организации с помощью учетных записей MSA или GitHub без ограничений.

Что такое команда?

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

Создание команды для каждой отдельной группы продуктов или компонентов

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

Что такое проект?

Проект в Azure DevOps содержит следующий набор функций:

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

На следующем изображении вымышленная компания Contoso имеет четыре проекта в организации Contoso-Manufacturing.

Изображение организации с четырьмя проектами

Сколько проектов вам нужно?

Чтобы начать использовать службу Azure DevOps, например Azure Boards, Azure Repos или Azure Pipelines, можно по крайней мере один проект. При создании организации создается проект по умолчанию. В проекте по умолчанию есть репозиторий кода для начала работы, невыполненной работы для отслеживания работы и по крайней мере одного конвейера, чтобы начать автоматизацию сборки и выпуска.

В организации можно выполнить любой из следующих подходов:

  • Создание одного проекта, содержащего множество репозиториев и команд
  • Создание множества проектов, каждый из которых содержит собственный набор команд, репозиториев, сборок, рабочих элементов и других элементов.

Даже если у вас есть множество команд, работающих над сотнями различных приложений и проектов программного обеспечения, вы можете управлять ими в рамках одного проекта в Azure DevOps. Однако если вы хотите управлять более детальной безопасностью между проектами программного обеспечения и их командами, рассмотрите возможность использования многих проектов. На самом высоком уровне изоляции является организация, где каждая организация подключена к одному клиенту Microsoft Entra. Однако один клиент Microsoft Entra может быть подключен ко многим организациям Azure DevOps.

Примечание.

Если для организации включена функция "Ограничить видимость пользователей и совместная работа с определенными проектами", пользователи, добавленные в группу "Пользователи с областью проекта", не смогут получить доступ к проектам, к которым они не были добавлены. Дополнительные сведения и важные вызовы, связанные с безопасностью, см. в статье "Управление организацией", ограничение видимости пользователей для проектов и многое другое.

Один проект

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

Совет

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

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

Многие проекты

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

Совет

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

Azure DevOps предоставляет кросспроектные возможности для управления работой.

Может потребоваться добавить другой проект из-за следующих сценариев:

  • Запрет доступа к информации в проекте или управление ими
  • Поддержка пользовательских процессов отслеживания работы для конкретных бизнес-подразделений в организации
  • Поддержка полностью отдельных бизнес-подразделений с собственными административными политиками и администраторами
  • Поддержка действий по настройке тестирования или добавление расширений перед развертыванием изменений в рабочем проекте

При рассмотрении многих проектов следует помнить, что переносимость репозитория Git упрощает перенос репозиториев (включая полную историю) между проектами. Другие журналы нельзя перенести между проектами. Примерами являются журнал запросов на отправку и вытягивание.

При сопоставлении проектов с бизнес-подразделениями ваша компания получает одну организацию и настраивает множество проектов с одним или несколькими проектами, представляющими бизнес-подразделение. Все активы Azure DevOps компании содержатся в этой организации и находятся в определенном регионе (например, в Западной Европе). Рассмотрим следующие рекомендации по сопоставлению проектов с бизнес-подразделениями:

Один проект, многие команды Одна организация, множество проектов и команд Многие организации
Общие рекомендации Лучше всего подходит для небольших организаций или крупных организаций с высоким уровнем соответствия команд. Хорошо, если разные усилия требуют разных процессов. Полезно в рамках миграции прежних версий TFS и для жестких границ безопасности между организациями. Используется с несколькими проектами и командами в каждой организации.
Масштабировать Поддерживает десятки тысяч пользователей и сотни команд, но лучше всего в этом масштабе, если все команды работают над соответствующими усилиями. То же, что и с одним проектом, но многие проекты могут быть проще.
Обработать Выровненные процессы между командами; гибкость команды для настройки досок, панелей мониторинга и т. д. Независимые процессы для каждого проекта. Например, различные типы рабочих элементов, настраиваемые поля и т. д. То же самое, что и многие проекты.
Совместная работа Максимальная видимость по умолчанию и повторное использование между работой и ресурсами разных команд. Хорошая видимость и повторное использование возможны, но проще скрыть ресурсы между проектами, будь то преднамеренным. Низкая видимость, совместная работа и повторное использование между организациями.
Сводка отчетов и управление портфелем Лучшие возможности для развертывания между командами и координации между командами. Хорошая отчетность, возможная в проектах. Сложнее для межпроектной координации и координации команд. Нет свертки или координации между организациями.
Безопасность и изоляция Может заблокировать ресурсы на уровне команды, но по умолчанию — это открытая видимость и совместная работа. Улучшена возможность блокировки между проектами. По умолчанию обеспечивает хорошую видимость проектов и хорошую изоляцию между проектами. Жесткие границы между организациями; отличная изоляция и минимальная возможность совместного использования между организациями.
Переключение контекста Самый простой для совместной работы команд и для пользователей, чтобы переключаться между усилиями. Относительно легко для пользователей работать вместе и переключать контексты между усилиями. Труднее для пользователей работать в разных организациях.
Перегрузка информации По умолчанию все ресурсы видны пользователям, которые используют "избранное" и аналогичные механизмы, чтобы избежать "перегрузки информации". Снижение риска перегрузки информации; большинство ресурсов проекта, скрытых через границы проекта. Ресурсы в разных организациях изолированы, что снижает риск перегрузки информации.
Административные издержки Большая часть администрирования делегируется отдельным командам. Самый простой для лицензирования пользователей и администрирования на уровне организации. Если требуется выравнивание между усилиями, может потребоваться дополнительная работа. Больше администрирования на уровне проекта. Дополнительные затраты, но могут быть полезны, если проекты имеют разные административные потребности. Как и в случае с большими проектами, есть больше административных накладных расходов, что обеспечивает большую гибкость между организациями.

Репозитории структуры и управление версиями в проекте

Рассмотрим конкретную стратегическую работу, ограниченную одной из организаций, созданных ранее, и которые нуждаются в доступе. Используйте эти сведения для имени и создания проекта. Этот проект имеет URL-адрес, определенный в созданной организации, и его можно получить по адресу https://dev.azure.com/{organization-name}/{project-name}.

Настройте проект в параметрах проекта.

Снимок экрана: кнопка

Дополнительные сведения об управлении проектами см. в статье "Управление проектами" в Azure DevOps. Проект можно переместить в другую организацию, переносив данные. Дополнительные сведения о переносе проекта см. в обзоре миграции.

Управление управлением версиями

В проектах, где включена служба Azure Repos, репозитории управления версиями могут хранить и изменять код. При настройке репозиториев следует учитывать следующие параметры.

Git vs. система управления версиями Team Foundation (TFVC)

Azure Repos предлагает следующие системы управления версиями для команд, которые можно выбрать:

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

TFVC — это централизованная система управления версиями, которая также доступна. В отличие от Git, для проекта допускается только один репозиторий TFVC. Но в этом репозитории, папках и ветвях используются для упорядочивания кода для нескольких продуктов и служб, если требуется. При необходимости проекты могут использовать как TFVC, так и Git.

Monorepo и один репозиторий для каждой службы

Развертывание различных независимых служб из monorepo может быть эффективным для небольших команд, направленных на создание раннего импульса. Однако эта стратегия может стать проблематичной, так как команда растет из-за нескольких факторов:

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

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

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

Один или несколько репозиториев в проекте

Нужно ли настроить несколько репозиториев в одном проекте или настроить репозиторий для каждого проекта? Следующие рекомендации относятся к функциям планирования и администрирования в этих репозиториях.

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

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

На основе вашего решения для одного или нескольких репозиториев на следующих факторах и советах:

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

Совет

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

Общий репозиторий и вилку репозиториев

Рекомендуется использовать общий репозиторий в доверенной организации. Разработчики используют ветви для обеспечения изоляции их изменений друг от друга. С хорошей стратегией ветвления и выпуска один репозиторий может масштабироваться для поддержки параллельной разработки для более чем тысячи разработчиков. Дополнительные сведения о стратегии ветвления и выпуска см. в статье "Внедрение стратегии ветвления Git" и "Поток выпуска: наша стратегия ветвления".

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

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

Схема, показывающая структуру организации для компании.

Управление временными и общими ресурсами

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

  • Временные среды: временные среды являются кратковременными и используются для таких задач, как тестирование, разработка или промежуточное выполнение. Чтобы эффективно управлять этими средами, выполните следующие действия.
    • Отдельные репозитории и конвейеры: каждая временная среда и связанные с ней ресурсы, например Функции Azure, должны иметь собственный репозиторий и конвейер. Это разделение позволяет одновременно развертывать и откатывать среду и ее ресурсы, что упрощает их развертывание и удаление по мере необходимости.
    • Пример. Создание репозитория и конвейера специально для среды разработки, включая все необходимые ресурсы, такие как Функции Azure, учетные записи хранения и другие службы.
  • Общие ресурсы: общие ресурсы обычно являются длительными и используются в нескольких средах. Эти ресурсы часто имеют более длительное время спины и более высокие затраты. Чтобы эффективно управлять общими ресурсами, выполните приведенные ниже действия.
    • Отдельные репозитории и конвейеры: общие ресурсы, такие как База данных SQL Azure, должны иметь собственный репозиторий и конвейер. Это разделение гарантирует, что временные среды могут использовать эти общие ресурсы, что делает их развертывания более быстрыми и экономичными.
    • Пример. Создание репозитория и конвейера для База данных SQL Azure, который можно использовать несколькими временными средами.
  • Ресурсы общей инфраструктуры: общие ресурсы инфраструктуры, такие как виртуальные частные облака и подсети, также известные как целевые зоны, также должны иметь собственные репозитории и конвейеры. Такой подход гарантирует, что инфраструктура управляется согласованно и может повторно использоваться в разных средах.
    • Пример. Создание репозитория и конвейера для конфигурации VPC и подсети, на которые можно ссылаться другими репозиториями и конвейерами.

Дополнительные сведения о структуре организации

Выбор типа учетной записи администратора организации

При создании организации учетные данные, которые вы выполняете вход, определяют, какой поставщик удостоверений использует ваша организация. Создайте организацию с учетной записью Майкрософт или экземпляром Microsoft Entra. Используйте эти учетные данные для входа в новую организацию https://dev.azure.com/{YourOrganization}в качестве администратора.

Использование учетной записи Майкрософт

Используйте свою учетную запись Майкрософт, если вам не нужно проходить проверку подлинности пользователей для организации с идентификатором Microsoft Entra. Все пользователи должны войти в свою организацию с помощью учетной записи Майкрософт. Если у вас нет учетной записи Майкрософт, создайте учетную запись Майкрософт.

Введите пароль и войдите

Если у вас нет экземпляра Microsoft Entra, создайте его бесплатно из портал Azure или используйте учетную запись Майкрософт для создания организации. Затем вы можете подключить организацию к идентификатору Microsoft Entra.

Использование учетной записи Microsoft Entra

Возможно, у вас уже есть учетная запись Microsoft Entra, если вы используете Azure или Microsoft 365. Если вы работаете в компании, которая использует идентификатор Microsoft Entra для управления разрешениями пользователей, вероятно, у вас есть учетная запись Microsoft Entra.

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

Azure DevOps проверяет подлинность пользователей с помощью идентификатора Microsoft Entra, чтобы только пользователи, являющиеся членами этого каталога, имели доступ к вашей организации. При удалении пользователей из этого каталога они больше не могут получить доступ к вашей организации. Только определенные администраторы Microsoft Entra управляют пользователями в каталоге, поэтому администраторы управляют доступом к вашей организации.

Дополнительные сведения об управлении пользователями см. в разделе "Управление пользователями".

Сопоставление организаций с бизнес-подразделениями

Каждая бизнес-единица в вашей компании получает собственную организацию в Azure DevOps, а также собственный клиент Microsoft Entra. Вы можете настроить проекты в этих отдельных организациях, по мере необходимости, на основе команд или текущих работ.

Для более крупной компании можно создать несколько организаций с помощью разных учетных записей пользователей (скорее всего, учетных записей Microsoft Entra). Рассмотрим, какие группы и пользователи делятся стратегиями и работой, а также группировать их в определенные организации.

Например, вымышленная компания Fabrikam создала следующие три организации:

  • Fabrikam-Marketing
  • Fabrikam-Engineering
  • Fabrikam-Sales

У каждой организации есть отдельный URL-адрес, например:

  • https://dev.azure.com/Fabrikam-Marketing
  • https://dev.azure.com/Fabrikam-Engineering
  • https://dev.azure.com/Fabrikam-Sales

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

Совет

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