作業の追跡、処理、およびプロジェクトの制限

Azure DevOps サービス |Azure DevOps Server |Azure DevOps Server 2022

この記事では、作業の追跡操作とカスタマイズに関するAzure DevOps操作とオブジェクトの制限について説明します。 いくつかの実用的な制限も適用されます。 作業項目の種類 (WIT) をカスタマイズするときは、これらの制限を考慮してください。

ヒント

オブジェクト制限トラッカーを使用すると、すべての制限カテゴリにわたる組織のリソース使用状況をリアルタイムで把握できます。 詳細については、Azure DevOps。

作業項目とクエリ

作業項目とクエリ定義には、次の制限が適用されます。

Object なし
作業項目あたりの添付ファイル数 100
添付ファイルのサイズ 60 MB
長いテキスト フィールド 1M 文字
クエリ実行時間 30 秒
クエリ結果 20,000 アイテム
クエリの長さ 32,000 文字
フォルダーごとの共有クエリ 999 個のクエリ
作業項目ごとの作業項目リンク数 1,000
作業項目ごとの作業項目タグ 100
作業項目のリビジョン (REST API)* 10,000
プロジェクトごとのお気に入りのクエリ 200 個のクエリ

*Azure DevOps サービスの REST API では、10,000 更新プログラムの作業項目リビジョン制限が適用されます。 この制限は REST API の更新にのみ適用され、Web ポータルを介して行われた更新には影響しません。 API を使用して作業項目の更新を自動化し、この制限に達した場合は、既存の作業項目を更新するのではなく、追跡を続行する新しい作業項目を作成することを検討してください。

上限に達するとどうなりますか。

  • クエリの実行時間: クエリが停止し、タイムアウト エラーが返されます。 スコープを減らすために、より具体的なフィルター条件または日付範囲を追加します。
  • クエリ結果: 結果は 20,000 項目で切り捨てられます。エラーは表示されません。 フィルター条件を調整するか、クエリを複数の保存済みクエリに分割します。
  • 添付ファイルのサイズ: アップロード時に添付ファイルが拒否され、エラー メッセージが表示されます。 添付する前に、ファイルを圧縮または分割します。
  • 作業項目のリンク: 制限に達すると、新しいリンクがブロックされます。 関連するリンクを統合するか、古い作業項目をアーカイブすることを検討してください。
Object なし
長いテキスト フィールド 1M 文字
作業項目ごとの作業項目タグ 100
作業項目ごとの作業項目リンク数 1,000
作業項目あたりの添付ファイル数 100
添付ファイルのサイズ* 4 MB から 2 GB
クエリ実行時間 6 分
クエリ結果 20,000 アイテム
クエリの長さ 32,000 文字
フォルダーごとの共有クエリ 999 個のクエリ
プロジェクトごとのお気に入りのクエリ 200 個のクエリ

*既定の添付ファイルの最大サイズは 4 MB です。 最大サイズ 2 GB まで変更できます。

クエリがタイムアウトした場合、または返される結果が多すぎる場合は、クエリのパフォーマンスの最適化に関するガイダンスの クエリを定義するためのベスト プラクティス を参照してください。

バックログ、ボード、ダッシュボード、チーム

次の操作とオブジェクトの制限は、チーム、作業項目タグ、バックログ、ボードに適用されます。

コンポーネント なし
バックログ 10,000 件の作業項目が表示*
Boards 提案済みおよび完了済みの状態カテゴリのカードを除く 1,000 枚のカード
タスクボード 1,000 個のタスク
プロジェクトごとのエリア パス 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 項目を超える場合は、チームを追加し、いくつかの作業項目を新しいチームのバックログに移動することを検討してください。

上限に達するとどうなりますか。

  • バックログの表示: 表示制限を超える作業項目はバックログに表示されませんが、削除されません。 クエリを使用して、非表示のアイテムを検索して管理します。
  • ボード カード: 制限を超えたカードはボードビューに表示されません。 [提案済み] および [完了] 状態カテゴリのアイテムは、1,000 カードの制限にカウントされません。
  • ダッシュボードの制限: 制限に達すると、新しいダッシュボードを作成することはできません。 未使用のダッシュボードを確認して削除し、空き領域を設定します。

ヒント

ダッシュボードの制限に近づいている場合は、次のアクションを実行して数を減らします。

  • 最後にアクセスした日付を確認するか、チーム メンバーに確認してから、重複または未使用のダッシュボードを削除します。
  • データをエクスポートし、古いダッシュボードをアーカイブします。
  • ダッシュボードにウィジェットを追加して、同様のダッシュボードを結合して統合します。

その他の考慮事項

  • 変更日が 1 年より前の場合、バックログとボードには完了した作業項目や終了した作業項目は表示されません。 この動作は、バグではなく想定されています。 クエリを実行しても、これらの作業項目を見つけることができます。 作業項目をバックログまたはボードに再表示するには、変更 日 をリセットするためのマイナー更新を行います 。たとえば、コメントを追加したり、フィールド値を更新したりします。
  • 同じ型のバックログ項目を入れ子にしないでください。 詳細については、「 修正の並べ替えと入れ子の問題を参照してください。
  • 複数のチームに同じエリア パスを割り当てないようにします。 詳細については、 マルチチームボードビューの制限事項を参照してください。

次の操作の表示とオブジェクトの制限は、チーム、作業項目タグ、バックログ、ボードに適用されます。

コンポーネント なし
バックログ* 999 個の作業項目
Boards 400 枚のカード
プロジェクトごとのダッシュボード 500
タスクボード 800 個の作業項目
プロジェクトあたりの Teams 5,000
プロジェクトの組織またはコレクションごとの作業項目タグ 150,000
作業項目ごとの作業項目タグ 100
作業項目の種類ごとのテンプレート 100

*各バックログには、最大 999 個の作業項目を表示できます。 バックログがこの制限を超える場合は、新しいチームを作成し、作業項目の一部を新しいチームのバックログに移動することを検討してください。

その他の考慮事項

GitHub統合

GitHubでプロジェクトを<>統合する場合は、次の制限が適用されます。

統合 なし
Azure Boards Web UI 接続あたり 1,000 個の接続GitHub リポジトリ
Azure Boards API* 接続あたり 2,000 個の接続GitHub リポジトリ

*詳細については、「GitHub 接続 - 接続の取得GitHub」を参照>。

上限に達するとどうなりますか。 接続がリポジトリの制限に達した場合、その接続にリポジトリを追加することはできません。 新しいGitHub接続を作成して、リポジトリを追加します。

プロジェクト

Azure DevOps サービスでは、各組織が 1,000 プロジェクトに制限されています。 300 プロジェクトを超えると、Visual Studioからプロジェクトに接続するなどの特定のエクスペリエンスが低下する可能性があります。 プロジェクトが多い組織でパフォーマンスの問題が発生している場合は、プロジェクトを統合するか、複数の組織に作業を分散することを検討してください。

オンプレミスのAzure DevOps Serverでは、コレクションごとのプロジェクトにハード制限はありませんが、プロジェクトの数が 300 に近づくとパフォーマンスの問題が発生する可能性があります。 Visual Studioからプロジェクトに接続するなどの特定のエクスペリエンスは低下する可能性があります。

Azure DevOps サービスに移行する場合は、最大 1,000 プロジェクトの制限に従います。 コレクションがこの制限を超えている場合は、コレクションを分割するか、古いプロジェクトを削除します。 詳細については、「 Azure DevOps Server から Azure DevOps Services へのデータの読み取りを参照してください。

プロセスのカスタマイズ

プロセスに対して定義できるオブジェクトの数に制限があります。 詳細については、「作業追跡エクスペリエンスをカスタマイズする」を参照してください。

次の表に、継承およびホストされる XML プロセス モデルに対して定義できるオブジェクトの最大数を示します。 実際の制限も適用される場合があります。

Object 継承 ホストされた 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 MB 60 MB

Note

Hosted XML プロセス モデルでは、すべての WIT で指定されたすべてのグローバル リストに対して約 10,000 個の項目を定義できます。 Hosted XML プロセス モデルのその他の制限事項と準拠要件については、「 ホスト型 XML を使用する場合のプロセスのカスタマイズ」を参照してください。

次の表に、継承とオンプレミスの 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

Note

オンプレミスの XML プロセス モデルでは、すべての WIT で指定されたすべてのグローバル リストについて、合計約 10,000 個の項目を定義できます。

実際の制限

ハード オブジェクトの制限内にある場合でも、カスタム オブジェクトの数が増えるとパフォーマンスが低下する可能性があります。 次のガイダンスは、予測可能なパフォーマンスを得るためのMicrosoft推奨される動作範囲を表しています。 パフォーマンスの問題を最小限に抑えるには、次のガイダンスに従います。

  • 定義するユーザー設定フィールドの数を制限します。 すべてのユーザー設定フィールドは、プロセス、コレクション、または組織で許可される合計に影響します。 異なる WIT の同じフィールドに対して、ルールや候補リストなどのさまざまな動作を指定できます。

  • WIT に対して定義するルールの数を制限します。 WIT に対して複数のルールを作成できますが、他のルールは、ユーザーが作業項目を追加または変更するときにパフォーマンスに悪影響を与える可能性があります。

  • 定義するカスタム WIT の数を制限します。

  • 定義するレポート可能フィールドの数を制限します。 レポート可能フィールドは、データ ウェアハウスのパフォーマンスに影響を与える可能性があります。

作業項目ルールの検証が SQL の制限を超えています

プロジェクトごとに 1 つの SQL 式が定義され、作業項目が作成または更新されるたびに検証されます。 この式は、プロジェクト内のすべての作業項目の種類に対して指定されたルールの数に合わせて増加します。

フィールドの各動作修飾子は、部分式の数を増やします。 入れ子になったルール、遷移にのみ適用されるルール、または別のフィールドの値に条件付けされたルールにより、 IF ステートメントに条件が追加されます。

ユーザーが作業項目を保存すると、その作業項目タイプのフィールドに関連付けられているすべてのルールが検証されます。 式が特定のサイズまたは複雑さに達すると、SQL はそれを効率的に評価できなくなり、エラーが発生する可能性があります。 このエラーを解決するには、一部の WIT を削除するか、一部のルールを削除します。

ヒント

作業項目を保存するときにユーザーにエラーが表示され、ルールを大幅にカスタマイズした場合は、プロジェクト内のすべての WIT のルールの数を確認します。 条件付きルール (状態遷移時にのみ適用されるルールや別のフィールドの値に依存するルールなど) を減らすことは、式の複雑さの軽減に最も大きな影響を与えます。

転送率の制限

Azure DevOpsサービスは、サービスとしての多くのソフトウェア ソリューションと同様に、マルチテナントを使用してコストを削減し、スケーラビリティとパフォーマンスを向上させます。 優れたパフォーマンスを確保し、停止のリスクを最小限に抑えるために、Azure DevOps サービスでは、個人が使用できるリソースと、特定のコマンドに対して行うことができる要求の数が制限されます。 ユーザーがこれらの制限を超えると、サービスによって後続の要求が遅延またはブロックされる可能性があります。

ほとんどのレート制限は、REST API 呼び出しまたは最適化されていないクエリを通じて達成されます。 詳細については、「 レート制限 」と「 レート制限に達しないようにするためのベスト プラクティス」を参照してください。

移行とインポートの制限

オンプレミスのAzure DevOps Serverから Azure DevOps Services に移行する場合、コレクションは次のサイズ要件を満たす必要があります。

測る 推奨される制限
合計データベース サイズ 150 GB
最大の個々のテーブル 30 GB
データベース メタデータのサイズ 2 GB

コレクションがこれらの制限を超えると、データが転送される前に移行の検証が失敗します。 この問題を解決するには、データのクリーンアップやコレクションの分割などのオプションの インポートと移行のエラーのトラブルシューティング を参照してください。 完全な移行プロセスについては、「Azure DevOps Server から Azure DevOps Services へのデータの移行」を参照してください。

関連コンテンツ

  • Last updated on