Ограничения для отслеживания хода выполнения работы, процесса и проекта
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
В этой статье определяются ограничения операционных и объектов, размещенные на операциях отслеживания работы и настройке отслеживания работы. Помимо указанных жестких ограничений на выбор объектов, применяются определенные практические ограничения. При настройке типов рабочих элементов (WIT) учитывайте ограничения, размещенные на объектах.
Рабочие элементы и запросы
При определении рабочих элементов или выполнении запросов применяются следующие операционные ограничения.
| Object | Лимит |
|---|---|
| Вложения, добавленные в рабочий элемент | 100 |
| Размер вложения | 60 МБ |
| Длинное текстовое поле | 1 М символов |
| Время выполнения запроса | 30 секунд |
| Результаты запроса | 20 000 элементов |
| Длина запроса | 32 000 символов |
| Общие запросы в папке | 999 запросов |
| Ссылки рабочего элемента, назначенные рабочему элементу | 1,000 |
| Теги рабочих элементов, назначенные рабочему элементу | 100 |
| Редакции рабочих элементов (REST API) | 10,000 |
| Избранные запросы для каждого проекта | 200 запросов |
Ограничение на редакцию рабочих элементов в 10 000 действует для обновлений, сделанных через REST API для Azure DevOps Services. Это ограничение ограничивает обновления rest API, однако обновления с веб-портала не затрагиваются.
| Object | Лимит |
|---|---|
| Длинное текстовое поле | 1 М символов |
| Теги рабочих элементов, назначенные рабочему элементу | 100 |
| Ссылки рабочего элемента, назначенные рабочему элементу | 1,000 |
| Вложения, добавленные в рабочий элемент | 100 |
| Размер вложения | 4 МБ до 2 ГБ |
| Время выполнения запроса | 6 мин. |
| Результаты запроса | 20 000 элементов |
| Длина запроса | 32 000 символов |
| Общие запросы в папке | 999 запросов |
| Избранные запросы для каждого проекта | 200 запросов |
Максимальный размер вложений по умолчанию — 4 МБ. Максимальный размер можно изменить до 2 ГБ.
Сведения о повышении производительности запросов см. в разделе "Определение запроса и рекомендации".
Невыполненные работы, доски, панели мониторинга и команды
При работе с командами, тегами рабочих элементов, невыполненной работой и досками применяются следующие ограничения операционного отображения и объектов.
| Пользовательский интерфейс | Лимит |
|---|---|
| Журналы невыполненных работ | 10 000 рабочих элементов |
| Boards | 1000 карта (за исключением этих карта в категориях состояния предлагаемого и завершенного рабочего процесса) |
| Панель задач | 1000 задач |
| Пути к области | 10 000 на каждый проект |
| Глубина пути к области | 14 |
| Пути к областям для каждой команды | 300 |
| Пути итерации | 10 000 на каждый проект |
| Глубина пути итерации | 14 |
| Пути итерации для каждой команды | 300 |
| Панели мониторинга проекта | 500 на проект |
| Панели мониторинга группы | 500 на команду |
| Команды | 5 000 на проект |
| Теги рабочих элементов | 150 000 определений тегов для каждой организации или коллекции |
| Планы доставки для каждого проекта | 1,000 |
| Шаблоны для каждого типа рабочего элемента | 100 |
Каждая невыполненная работа может отображать до 10 000 рабочих элементов. Это ограничение на то, что может отображаться невыполненная работа, а не ограничение на количество рабочих элементов, которые можно определить. Если невыполненная работа превышает это ограничение, может потребоваться добавить команду и переместить некоторые рабочие элементы в невыполненную работу другой команды.
Дополнительные примечания:
- Завершенные или закрытые рабочие элементы не отображаются в невыполненных работах и досках после того, как их дата изменения больше года. Вы по-прежнему можете перечислить эти элементы с помощью запроса. Если вы хотите, чтобы они отображались в невыполненной работы или доске, вы можете внести в них незначительные изменения, которые сбрасывают часы для отображения.
- Избегайте вложения элементов невыполненной работы одного типа. Дополнительные сведения см. в статье "Исправление проблем с переупорядочением и вложением".
- Избегайте назначения одного пути к одной области нескольким командам. Дополнительные сведения см. в разделе "Ограничения многокомандных представлений канбанов".
- По умолчанию ограничения рабочих элементов могут быть изначально настроены на более низкие значения.
При работе с командами, тегами рабочих элементов, невыполненной работой и досками применяются следующие операционные ограничения. Ограничения по умолчанию и максимальные.
| Пользовательский интерфейс | Лимит |
|---|---|
| Журналы невыполненных работ | 999 рабочих элементов |
| Boards | 400 карта |
| Панели мониторинга для каждого проекта | 500 |
| Панель задач | 800 рабочих элементов |
| Команды | 5 000 на проект |
| Теги рабочих элементов | 150 000 определений тегов для каждого проекта |
| Шаблоны для каждого типа рабочего элемента | 100 |
Каждая невыполненная работа может отображать до 999 рабочих элементов. Если невыполненная работа превышает это ограничение, может потребоваться добавить команду и переместить некоторые рабочие элементы в невыполненную работу другой команды.
Дополнительные примечания:
- Избегайте вложения элементов невыполненной работы одного типа. Дополнительные сведения см. в статье "Исправление проблем с переупорядочением и вложением".
- Избегайте назначения одного пути к одной области нескольким командам. Дополнительные сведения см. в разделе "Ограничения многокомандных представлений канбанов".
Для локальной модели процесса XML можно изменить ограничения невыполненной работы и области задач, изменив файл ProcessConfiguration.xml. Дополнительные сведения см. в справочнике по XML-элементу конфигурации процесса.
Проекты
Azure DevOps Services ограничивает каждую организацию до 1000 проектов на организацию, что увеличивается за предыдущий предел в 300 проектов.
Примечание.
Более 300 проектов, таких как подключение к проекту из Visual Studio, может привести к снижению производительности. Для локального сервера Azure DevOps Server не существует жестких ограничений на количество проектов. Однако вы можете найти проблемы с производительностью, если число проектов приближается к 300. Если вы планируете перенести локальную коллекцию в Azure DevOps Services, необходимо соблюдать максимальное ограничение в 1000 проектов. Если в коллекции более 1000 проектов, необходимо разделить коллекцию или удалить старые проекты.
Дополнительные сведения см. в статье "Миграция данных из Azure DevOps Server в Azure DevOps Services".
Настройка процесса
Ряд ограничений накладывается на количество объектов, которые можно определить для процесса. Дополнительные сведения о моделях процессов см. в статье "Настройка взаимодействия с отслеживанием работы".
В следующей таблице перечислены максимальное количество объектов, которые можно определить для моделей процессов наследования и размещения XML. Хотя они представляют жесткие ограничения, практические ограничения также могут применяться.
| Object | Наследование | Размещенный XML |
|---|---|---|
| Количество процессов, которые могут быть в организации | 128 | 64 |
| Типы рабочих элементов, определенные для процесса | 64 | 64 |
| Поля, определенные для организации | 8192 | 8192 |
| Поля, определенные для процесса | 1024 | 1024 |
| Поля, определенные для типа рабочего элемента | 1024 | 1024 |
| Списки выбора, определенные для организации или коллекции | 2048 | - |
| Элементы списка выбора, определенные для списка | 2048 | 2048 |
| Длина символа элемента выбора | 256 | - |
| Состояния рабочего процесса, определенные для типа рабочего элемента | 32 | 16 |
| Правила, определенные для типа рабочего элемента | 1024 | 1024 |
| Действия, определенные для правила | 10 | 10 |
| Уровни невыполненной работы портфеля, определенные для процесса | 5 | 5 |
| Категории, определенные для процесса | - | 32 |
| Глобальные списки, определенные для процесса | - | 256 |
| Элементы списка, определенные в глобальном списке | - | 1024 |
| Размер вложения рабочего элемента | 60 МБ | 60 МБ |
Дополнительные ограничения и требования к соответствию модели размещенного XML-процесса см. в разделе "Настройка процесса при использовании размещенного XML".
Примечание.
Для модели размещенного XML-процесса можно определить приблизительное количество элементов 10K для всех глобальных списков, указанных во всех WIT.
В следующей таблице перечислены максимальное количество объектов, которые можно определить для моделей процессов наследования и локального XML-процесса. Хотя они представляют жесткие ограничения, практические ограничения также могут применяться.
| Object | Наследование | Локальный 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 можно определить приблизительное количество элементов 10K для всех глобальных списков, указанных во всех WIT.
Практические ограничения
Рекомендуется рассмотреть следующие рекомендации, чтобы свести к минимуму проблемы с производительностью.
- Свести к минимуму количество определяемых настраиваемых полей. Все настраиваемые поля вносят вклад в общий объем, разрешенный для процесса, коллекции или организации. Обратите внимание, что можно указать другое поведение для одного поля в другом WIT. То есть можно указать различные правила, списки выбора и многое другое.
- Свести к минимуму количество правил, которые вы определяете для WIT. Хотя для типа рабочего элемента можно создать несколько правил, это может негативно повлиять на производительность при добавлении и изменении рабочих элементов пользователем. Когда пользователи сохраняют рабочие элементы, система проверяет все правила, связанные с полями для типа рабочего элемента. При определенных условиях выражение проверки правила будет слишком сложным для вычисления SQL.
- Сведите к минимуму количество определяемых пользовательских типов рабочего элемента.
- Свести к минимуму количество определяемых настраиваемых полей. Все настраиваемые поля вносят вклад в общий объем, разрешенный для процесса, коллекции или организации. Обратите внимание, что можно указать другое поведение для одного поля в другом WIT. То есть можно указать различные правила, списки выбора и многое другое.
- Свести к минимуму количество правил, которые вы определяете для WIT. Хотя для типа рабочего элемента можно создать несколько правил, это может негативно повлиять на производительность при добавлении и изменении рабочих элементов пользователем. Когда пользователи сохраняют рабочие элементы, система проверяет все правила, связанные с полями для типа рабочего элемента. При определенных условиях выражение проверки правила будет слишком сложным для вычисления SQL.
- Сведите к минимуму количество определяемых пользовательских типов рабочего элемента.
- Свести к минимуму количество определяемых вами полей. Отчетируемые поля влияют на производительность хранилища данных.
Примечание.
Проверка правил рабочих элементов превышает ограничения SQL: одно выражение SQL определяется для каждого проекта для проверки рабочих элементов всякий раз, когда они создаются или обновляются. Это выражение растет с числом правил, заданных для всех типов рабочих элементов, определенных для проекта. Каждый квалификатор поведения, указанный для поля, приводит к увеличению числа вложенных выражений. Вложенные правила, правила, которые применяются только к переходу или условию значения другого поля, приводят к добавлению дополнительных условий в инструкцию IF. Когда выражение достигает определенного размера или сложности, SQL больше не может оценить его и создает ошибку. Удаление некоторых WIT или устранение некоторых правил может устранить ошибку.
Ограничения скорости
Чтобы сократить затраты и повысить масштабируемость и производительность, Azure DevOps Services, как и многие решения Software-as-Service, используют многотенантность. Чтобы обеспечить хорошую производительность и снизить вероятность сбоя, Azure DevOps Services ограничивает ресурсы, которые могут использовать отдельные пользователи, и количество запросов, которые они могут сделать для определенных команд. При превышении этих ограничений последующие запросы могут быть отложены или заблокированы.
Большинство ограничений скорости достигаются через вызовы REST API или неоптимизированные запросы. Дополнительные сведения см. в следующих разделах:
Ограничения миграции и импорта
При определении миграции из локальной среды в Azure DevOps Services может возникнуть несколько ограничений размера. Вот эти ограничения:
- Размер базы данных превышает рекомендуемый размер
- Максимальный размер таблицы превышает рекомендуемый размер
- Размер метаданных базы данных превышает поддерживаемый размер
Дополнительные сведения см. в статье "Миграция данных из Azure DevOps Server в Azure DevOps Services " и устранение ошибок при импорте и миграции.
Связанные статьи
Связанные ресурсы
Кері байланыс
Жақында қолжетімді болады: 2024 жыл бойы біз GitHub Issues жүйесін мазмұнға арналған кері байланыс механизмі ретінде біртіндеп қолданыстан шығарамыз және оны жаңа кері байланыс жүйесімен ауыстырамыз. Қосымша ақпаратты мұнда қараңыз: https://aka.ms/ContentUserFeedback.
Жіберу және пікірді көру