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

Сервисы Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

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

Структура стратегического планирования

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

Основные решения по структуре

Представьте себе и ответьте на эти фундаментальные вопросы, чтобы направить структуру Azure DevOps.

Уровень организации:

• Сколько организаций вам нужно? — Рассмотрите вопросы безопасности, соответствия требованиям и разделения бизнес-подразделений.
• Как сопоставлять организации с бизнес-подразделениями — согласование с потребностями корпоративной структуры и управления.

Уровень проекта:

• Сколько проектов вам нужно? — Балансируйте совместную работу с безопасностью и автономией.
• Стратегии сопоставления проектов — подключение проектов к бизнес-функциям и структурам команд.

Уровень команды и репозитория:

• Структура команды — оптимизация для гибкой доставки и владения продуктами.
• Организация репозитория — поддержка рабочих процессов разработки и развертывания.

Рекомендации по поддержке

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

Общие сведения о организациях Azure DevOps

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

• Централизация выставления счетов и лицензирования в связанных проектах и командах.
• Установите границы безопасности с различными элементами управления доступом и политиками.
• Предоставьте административную изоляцию для различных бизнес-единиц или требований соответствия требованиям.
• Подключитесь к поставщикам удостоверений , таким как Идентификатор Microsoft Entra для единой проверки подлинности.

Преимущества организации и бесплатный тариф

Каждая организация предоставляет услуги бесплатного уровня до пяти пользователей.

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

Общие шаблоны организации:

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

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

Начните с одной организации и развернитесь , только если у вас есть конкретные бизнес-требования, которые требуют разделения.

Критерии принятия решений для нескольких организаций

Создайте дополнительные организации при необходимости:

Разделение безопасности и соответствия требованиям:

• Различные нормативные требования, такие как SOX, HIPAA или PCI-DSS
• Особые требования к изоляции данных клиента
• Отдельные журналы аудита и отчеты о соблюдении

Требования к структуре бизнеса:

• Независимые бизнес-подразделения с отдельным управлением ИТ-отделом
• Различные требования к выставлению счетов и центру затрат
• Различные подключения поставщика удостоверений, такие как разные клиенты Microsoft Entra

Административные границы:

• Разные группы администраторов без перекрытий
• Отдельные политики и элементы управления организации
• Независимые соглашения об уровне обслуживания

Платформа оценки

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

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

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

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

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

Проекты предоставляют контейнер для разработки, содержащий следующие интегрированные службы:

• Azure Boards: гибкое планирование с невыполненной работой, спринтами и отслеживанием рабочих элементов.
• Azure Pipelines: непрерывная интеграция и автоматизация развертывания.
• Репозитории Azure Repos: репозитории Git или TFVC для управления исходным кодом.
• Планы тестирования Azure: интеграция ручного и автоматического тестирования.
• Общие ресурсы: вики-сайт, панели мониторинга и параметры уровня проекта.

В следующем примере Contoso Manufacturing использует четыре проекта для организации различных линий продуктов:

Преимущества и рекомендации по проекту

Проекты позволяют:

• Общие расписания итерации и таксономии между командами.
• Согласованные шаблоны процессов и типы рабочих элементов.
• Интегрированное управление отчетами и портфелем.
• Упрощенное управление пользователями и управление доступом.

Проекты предоставляют границы для:

• Разрешения на безопасность и доступ.
• Настройка процесса и отслеживание работы.
• Административные политики и управление.
• Отслеживание выделения ресурсов и выставления счетов.

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

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

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

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

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

Платформа принятия решений проекта

Выберите соответствующую структуру проекта в зависимости от потребностей совместной работы:

Подход к одному проекту:

• Лучше всего: небольшие организации или команды с жесткой совместной работой
• Преимущества: максимальная видимость, общие ресурсы, унифицированные отчеты
• Рассмотрите, когда: Команды работают над связанными продуктами с аналогичными циклами выпуска

Подход к нескольким проектам:

• Идеально: Независимые команды с различными требованиями
• Преимущества: улучшенные границы безопасности, настраиваемые процессы, автономия команды
• Учитывайте, когда существуют: различные требования к соответствию или отдельные подразделения бизнеса

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

Рассмотрим несколько проектов для:

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

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

Организация репозиториев и управление версиями в проекте

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

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

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

Стратегия репозитория и управление версиями

Настройте стратегию репозитория на основе размера группы, архитектуры продукта и требований к развертыванию.

Выбор системы управления версиями

Выберите между Git и Team Foundation Version Control (TFVC):

Репозитории Git:

• Рекомендуемый подход для современных рабочих процессов разработки
• Неограниченные репозитории для каждого проекта
• Управление распределенными версиями с гибким ветвлением
• Интеграция с большинством средств разработки и систем CI/CD

Управление версиями Team Foundation (TFVC):

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

Шаблоны организации репозитория

Стратегия Monorepo:

• Лучше всего: небольшие команды, развивающиеся благодаря связанным сервисам
• Преимущества: упрощенное совместное использование и координированные изменения
• Проблемы: сложность знаний увеличивается с ростом команды; непреднамеренное соединение служб; сложное отслеживание изменений

Отдельная стратегия репозиториев:

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

Стратегия согласования репозитория и проекта

Один проект с несколькими репозиториями:

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

Несколько проектов с выделенными репозиториями:

• Лучше всего: продукты с независимыми расписаниями или отдельными требованиями
• Преимущества: независимая настройка, отдельное управление, четкие границы

Факторы принятия решений для организации репозитория:

• Зависимости кода: размещение независимо развертываемых продуктов и служб в отдельных репозиториях
• Потребности в координации. Сохранение связанных баз кода вместе при ожидаемых координированных изменениях
• Архитектура: поддерживать существующие монолиты в отдельных репозиториях; отделить независимые службы
• Доступ к группе. Реализация правильного управления разрешениями для управления созданием репозитория

Общие репозитории против форкнутых репозиториев

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

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

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

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

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

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

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

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

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

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

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

Если у вас нет экземпляра Microsoft Entra, создайте его бесплатно из портала Azure или используйте учетную запись Microsoft для создания организации. Затем вы можете подключить организацию к идентификатору 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-Инжиниринг
• Fabrikam-Sales

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

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

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

Связанный контент

• Создание организации
• Создание проекта
• Подключение организации к Microsoft Entra ID
• Настройка выставления счетов
• Настройка параметров пользователя