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

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | Team Foundation Server 2018 — Team Foundation Server 2013

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

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

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

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

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

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

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

Внимание!

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

Сколько организаций требуется?

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

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

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

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

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

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

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

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

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

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

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

Сколько требуется проектов?

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

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

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

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

Примечание

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

Один проект

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

Совет

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

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

Множество проектов

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

Совет

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

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

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

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

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

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

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

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

Рассмотрите конкретную стратегическую работу, ограниченную одной из ранее созданных организаций и имеющих доступ к. Используйте эти сведения, чтобы присвоить имя и создать проект. Этот проект имеет URL-адрес, определенный в Организации, в которой вы создали его, и доступ к нему можно получить по протоколу HTTPS: / /дев.Азуре.ком/{организатион-наме}/{Прожект-наме}..

настройте проект, посетив его URL-адрес и выбрав параметры Project в нижней левой части страницы.

снимок экрана, показывающий кнопку параметров Project.

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

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

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

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

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

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

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

Один и многие репозиториев

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

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

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

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

Примечание

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

Общий репозиторий и разветвленные репозиториев

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для более крупной компании можно создать несколько организаций, использующих разные учетные записи пользователей (наиболее вероятные учетные записи Azure AD). Определите, какие группы и пользователи совместно используют стратегии и работают, и сгруппируйте их в определенные организации. Например, компания 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. Организации предназначены для одной компании, но в основном изолированы друг от друга. Вам не нужно разделять ничего, однако следует создавать границы только в том случае, если это имеет смысл для вашего бизнеса. Можно легко секционировать существующую организацию с проектами, чем объединять разные организации.