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