Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
службы Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022
В этой статье описываются ограничения операций и объектов, которые Azure DevOps помещает операции отслеживания работы и настройки. Также применяются некоторые практические ограничения. Учитывайте эти ограничения при настройке типов рабочих элементов (WIT).
Совет
Используйте средство отслеживания ограничений объектов для видимости использования ресурсов вашей организации в режиме реального времени во всех категориях ограничений. Дополнительные сведения см. в разделе Introducing Object Limit Tracker в Azure DevOps.
Рабочие элементы и запросы
Следующие ограничения применяются к определениям рабочих элементов и запросов.
| Объект | Лимит |
|---|---|
| Вложения на рабочий элемент | 100 |
| Размер вложения | 60 МБ |
| Длинное текстовое поле | 1M символов |
| Время выполнения запроса | 30 секунд |
| Результаты запроса | 20 000 элементов |
| Длина запроса | 32 000 символов |
| Общие запросы для каждой папки | 999 запросов |
| Ссылки рабочих элементов на рабочий элемент | 1,000 |
| Теги рабочих элементов на рабочий элемент | 100 |
| Редакции рабочих элементов (REST API)* | 10 000 |
| Избранные запросы для каждого проекта | 200 запросов |
*REST API для служб Azure DevOps применяет ограничение редакции рабочего элемента в размере 10 000 обновлений. Это ограничение применяется только к обновлениям REST API и не влияет на обновления, внесенные через веб-портал. Если вы автоматизаете обновления рабочих элементов через API и столкнулись с этим ограничением, попробуйте создать новый рабочий элемент для продолжения отслеживания вместо обновления существующего.
Что происходит при достижении предела:
- Время выполнения запроса: Запрос останавливается и возвращает ошибку времени ожидания. Добавьте более конкретные условия фильтра или диапазоны дат для уменьшения области.
- Результаты запроса: Результаты усечены на 20 000 элементов — ошибка не отображается. Укажите условия фильтра или разбиите запрос на несколько сохраненных запросов.
- Размер вложения: Вложение отклоняется во время отправки с сообщением об ошибке. Сжать или разделить файл перед присоединением.
- Ссылки на рабочий элемент: Новые ссылки блокируются при достижении ограничения. Рассмотрите возможность консолидации связанных ссылок или архивации старых рабочих элементов.
| Объект | Лимит |
|---|---|
| Длинное текстовое поле | 1M символов |
| Теги рабочих элементов на рабочий элемент | 100 |
| Ссылки рабочих элементов на рабочий элемент | 1,000 |
| Вложения на рабочий элемент | 100 |
| Размер вложения* | 4 МБ до 2 ГБ |
| Время выполнения запроса | 6 мин. |
| Результаты запроса | 20 000 элементов |
| Длина запроса | 32 000 символов |
| Общие запросы для каждой папки | 999 запросов |
| Избранные запросы для каждого проекта | 200 запросов |
*Максимальный размер вложений по умолчанию — 4 МБ. Максимальный размер можно изменить до 2 ГБ.
Если запрос истекает или возвращает слишком много результатов, ознакомьтесь с рекомендациями по определению запроса для оптимизации производительности запросов.
Невыполненные работы, доски, панели мониторинга и команды
Следующие ограничения операций и объектов применяются к командам, тегам рабочих элементов, невыполненной работе и доскам.
| Компонент | Лимит |
|---|---|
| Невыполненные задания | 10 000 отображаемых рабочих элементов* |
| Доски | 1000 карт, за исключением карточек в категориях предлагаемых и завершенныхсостояний |
| Панель задач | 1000 задач |
| Пути к областям для каждого проекта | 10 000 |
| Пути к областям для каждой команды | 300 |
| Глубина пути к области | 14 уровней |
| Пути итерации для каждого проекта | 10 000 |
| Пути итерации для каждой команды | 300 |
| Глубина пути итерации | 14 уровней |
| Project панели мониторинга на project | 500, доступный на уровне проекта всем пользователям с доступом к проекту |
| Панели мониторинга группы для каждой команды | 500, относящиеся к команде и используемые для отслеживания метрик и данных для конкретной команды |
| Teams для каждого проекта | 5,000 |
| Теги рабочих элементов на рабочий элемент | 100 |
| Тег рабочего элемента и имена меток запроса на вытягивание для каждой организации или коллекции | 150 000 объединенных |
| Планы доставки для каждого проекта | 1,500 |
| Шаблоны для каждого типа рабочего элемента | 100 |
*Каждая невыполненная работа может отображать до 10 000 рабочих элементов, но нет определенного ограничения на количество рабочих элементов, которые можно определить. Если невыполненная работа превышает 10 000 элементов, попробуйте добавить команду и переместить некоторые рабочие элементы в невыполненную работу новой команды.
Что происходит при достижении предела:
- Отображение невыполненной работы: Рабочие элементы за пределом отображения скрыты из невыполненной работы, но не удаляются. Используйте запрос для поиска скрытых элементов и управления ими.
- Карточки доски: Карточки за пределы скрыты от представления доски. Элементы в категориях предлагаемых и завершенных состояний не учитываются в отношении ограничения на 1000 карт.
- Ограничение панели мониторинга: Создание новых панелей мониторинга невозможно после достижения ограничения. Просмотрите и удалите неиспользуемые панели мониторинга для свободного места.
Совет
Если вы приближаетесь к ограничениям панели мониторинга, выполните следующие действия, чтобы уменьшить их количество.
- Просмотрите дату последнего доступа или проверьте с участниками команды, а затем удалите панели мониторинга, повторяющиеся или неиспользуемые.
- Экспортируйте данные, а затем архивируйте старые панели мониторинга.
- Объединение и консолидация аналогичных панелей мониторинга путем добавления дополнительных мини-приложений на панели мониторинга.
Дополнительные рекомендации
- Невыполненные и доски не отображают завершенные или закрытые рабочие элементы, если их дата изменения старше года. Это поведение ожидается, а не ошибка. Эти рабочие элементы по-прежнему можно найти, выполнив запрос. Чтобы сделать рабочий элемент вновь появиться в невыполненной работе или доске, сделайте любое дополнительное обновление, чтобы сбросить ее измененную дату , например добавить комментарий или обновить значение поля.
- Избегайте гнездования элементов невыполненной работы одного и того же типа. Дополнительные сведения см. в разделе "Исправление проблем с переупорядочением и вложением".
- Избегайте назначения одного пути к одной области нескольким командам. Дополнительные сведения см. в разделе "Ограничения представлений многофакторной доски".
Следующие операционные ограничения отображения и объектов применяются к командам, тегам рабочих элементов, невыполненной работе и доскам.
| Компонент | Лимит |
|---|---|
| Задержек* | 999 рабочих элементов |
| Доски | 400 карточек |
| Панели мониторинга для каждого проекта | 500 |
| Панель задач | 800 рабочих элементов |
| Teams для каждого проекта | 5,000 |
| Тег рабочего элемента и имена меток запроса на вытягивание для каждой организации или коллекции | 150 000 объединенных |
| Теги рабочих элементов на рабочий элемент | 100 |
| Шаблоны для каждого типа рабочего элемента | 100 |
*Каждая невыполненная работа может отображать до 999 рабочих элементов. Если невыполненная работа превышает это ограничение, рассмотрите возможность создания новой команды и перемещения некоторых рабочих элементов в невыполненную работу новой команды.
Дополнительные рекомендации
- Избегайте гнездования элементов невыполненной работы одного и того же типа. Дополнительные сведения см. в разделе "Исправление проблем с переупорядочением и вложением".
- Избегайте назначения одного пути к одной области нескольким командам. Дополнительные сведения см. в разделе "Ограничения представлений многофакторной доски".
- Для локальной модели xml-процессов можно изменить ограничения невыполненной работы и доски, изменив файлProcessConfiguration.xml . Дополнительные сведения см. в справочнике по XML-элементу конфигурации процесса.
интеграция GitHub
Если вы integrate проект с помощью GitHub, применяются следующие ограничения.
| Интеграция | Лимит |
|---|---|
| веб-интерфейс Azure Boards | 2000 подключенных GitHub репозиториев на подключение |
| API Azure Boards* | 2000 подключенных GitHub репозиториев на подключение |
*Дополнительные сведения см. в разделе GitHub Подключения — получение подключений GitHub.
Что происходит при достижении предела: Когда подключение достигнет предела репозитория, вы не можете добавить в это подключение больше репозиториев. Создайте новое подключение GitHub для добавления дополнительных репозиториев.
Проекты
Azure DevOps Службы ограничивают каждую организацию 1000 проектов. Если вы выходите за рамки 300 проектов, некоторые возможности, такие как подключение к проекту из Visual Studio, могут снизиться. Если у вас возникли проблемы с производительностью в организации с большим количеством проектов, рассмотрите возможность объединения проектов или распределения работы в нескольких организациях.
Azure DevOps Server поддерживает не более 1000 проектов на коллекцию. Однако производительность может снизиться, так как число проектов приближается к 300, затрагивая такие возможности, как подключение к проекту из Visual Studio или Excel.
При миграции на службы Azure DevOps обратите внимание на максимальное ограничение в 1000 проектов. Если коллекция превышает это ограничение, разделите коллекцию или удалите старые проекты. Дополнительные сведения см. в разделе Migrate data from Azure DevOps Server to Azure DevOps Services.
Настройка процесса
Ограничения существуют по количеству объектов, которые можно определить для процесса. Дополнительные сведения см. в разделе "Настройка процесса отслеживания работы".
В следующей таблице перечислено максимальное число объектов, которые можно определить для моделей процессов наследования и размещения XML. Практические ограничения также могут применяться.
| Объект | Наследование | Размещенный XML |
|---|---|---|
| Количество процессов на организацию | 256 | 64 |
| Типы рабочих элементов на процесс | 64 | 64 |
| Поля для каждой организации | 8192 | 8192 |
| Поля для каждого процесса | 1024 | 1024 |
| Поля для каждого типа рабочего элемента | 1024 | 1024 |
| Списки выбора для каждой организации | 2048 | - |
| Элементы списка выбора для каждого списка | 2048 | 2048 |
| Длина строки символов элемента списка выбора | 256 | - |
| Состояния рабочего процесса на тип рабочего элемента | 32 | 16 |
| Страницы (вкладки) для каждого типа рабочего элемента | 16 | 16 |
| Группы на страницу | 32 | 32 |
| Правила для каждого типа рабочего элемента | 1024 | 1024 |
| Действия для каждого типа рабочего элемента | 1024 | 1024 |
| Действия для каждого правила | 10 | 10 |
| Уровни невыполненной работы портфеля на каждый процесс | 5 | 5 |
| Категории на процесс | - | 32 |
| Размер вложения рабочего элемента | 60 МБ | 60 МБ |
Примечание.
Для модели процесса размещенного XML можно определить приблизительно 10 000 элементов во всех глобальных списках, указанных во всех WIT. Сведения о других ограничениях и требованиях к соответствию модели размещенного XML-процесса см. в разделе "Настройка процесса при использовании размещенного XML".
В следующей таблице перечислены максимальное количество объектов, которые можно определить для моделей процессов наследования и локального XML-процесса. Практические ограничения также могут применяться.
| Объект | Наследование | Локальный XML-процесс |
|---|---|---|
| Количество процессов для каждой коллекции | 64 | 64 |
| Типы рабочих элементов на процесс | 64 | 64 |
| Поля для каждой коллекции | 8192 | 1024 |
| Поля для каждого процесса | 1024 | 1024 |
| Поля для каждого типа рабочего элемента | 1024 | 1024 |
| Списки выбора для каждой коллекции | 1024 | Нет данных |
| Элементы списка выбора для каждого списка | 2048 | 2048 |
| Длина строки символов элемента списка выбора | 256 | Нет данных |
| Состояния рабочего процесса на тип рабочего элемента | 32 | 16 |
| Правила для каждого типа рабочего элемента | 1024 | 1024 |
| Уровни невыполненной работы портфеля на каждый процесс | 5 | 5 |
| Категории на процесс | Нет данных | 32 |
| Глобальные списки на процесс | Нет данных | 256 |
| Список элементов на глобальный список | Нет данных | 1024 |
Примечание.
Для локальной модели процесса XML можно определить приблизительно 10 000 элементов для всех глобальных списков, указанных во всех WIT.
Практические ограничения
Даже если вы находитесь в пределах жестких объектов, производительность может снизиться по мере роста числа пользовательских объектов. В следующем руководстве представлен рекомендуемый Microsoft диапазон операций для прогнозируемой производительности. Чтобы свести к минимуму проблемы с производительностью, следуйте приведенным ниже рекомендациям.
Ограничить количество определяемых настраиваемых полей. Все настраиваемые поля вносят вклад в общий объем, разрешенный для процесса, коллекции или организации. Можно указать различные варианты поведения, такие как правила и списки выбора, для одного и того же поля в разных WIT.
Ограничить количество правил, которые вы определяете для WIT. Хотя можно создать несколько правил для WIT, другие правила могут отрицательно повлиять на производительность при добавлении или изменении рабочих элементов.
Ограничить количество определяемых пользовательских WIT.
Избегайте длительных рабочих элементов, связанных с несколькими сборками. Чем больше интегрированных в сборке ссылок на рабочий элемент, тем более вероятно, что вы увидите ошибки "Встроенная ссылка на сборку не удалось прочитать" для этого рабочего элемента. Помимо использования более коротких рабочих элементов, рекомендуется отключить "Автоматическое связывание рабочих элементов, включенных в этот запуск", для некоторых конвейеров или использования REST API для удаления ссылок сборки, которые больше не нужны.
- Ограничить количество определяемых полей, доступных для отчетов. Отчетные поля могут повлиять на производительность хранилища данных.
Проверка правил рабочих элементов превышает ограничения SQL
Одно выражение SQL определяется для каждого проекта для проверки рабочих элементов всякий раз, когда они создаются или обновляются. Это выражение увеличивается с числом правил, заданных для всех типов рабочих элементов в проекте.
Каждый квалификатор поведения для поля увеличивает количество вложенных выражений. Вложенные правила, правила, которые применяются только к переходу или правилам, заданным для значения другого поля, добавляют дополнительные условия в инструкцию IF .
При сохранении рабочих элементов система проверяет все правила, связанные с полями для этого типа рабочего элемента. Когда выражение достигает определенного размера или сложности, SQL больше не может эффективно оценить его и может создать ошибку. Чтобы устранить эту ошибку, удалите некоторые WIT или исключите некоторые правила.
Совет
Если пользователи видят ошибки при сохранении рабочих элементов и вы сильно настраиваете правила, просмотрите количество правил для всех WIT в проекте. Сокращение условных правил (например, применяемых только во время перехода состояния или зависящих от значения другого поля) оказывает наибольшее влияние на снижение сложности выражений.
Ограничения скорости
Azure DevOps службы, такие как многие решения программного обеспечения в качестве службы, используют мультитенантность для снижения затрат и повышения масштабируемости и производительности. Чтобы обеспечить хорошую производительность и свести к минимуму риск сбоев, Azure DevOps Services ограничивает ресурсы, которые могут использовать отдельные пользователи, и количество запросов, которые они могут сделать для определенных команд. Если пользователи превышают эти ограничения, служба может отложить или заблокировать последующие запросы.
Большинство ограничений скорости достигается через вызовы REST API или неоптимизированные запросы. Дополнительные сведения см. в разделе "Ограничения скорости " и "Рекомендации", чтобы избежать ограничения скорости удара.
Ограничения миграции и импорта
При миграции из локальной Azure DevOps Server в службы Azure DevOps коллекция должна соответствовать следующим требованиям к размеру:
| Мера | Рекомендуемое ограничение |
|---|---|
| Общий размер базы данных | 150 ГБ |
| Самая большая отдельная таблица | 30 ГБ |
| Размер метаданных базы данных | 2 ГБ |
Если коллекция превышает эти ограничения, проверка миграции завершается ошибкой до передачи данных. Сведения об устранении проблемы см. в разделе "Устранение неполадок при импорте и миграции " для параметров, включая очистку данных и разделение коллекции. Полный процесс миграции см. в разделе "Перенос данных из Azure DevOps Server в службы Azure DevOps".