作業の追跡、処理、およびプロジェクトの制限
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
この記事では、作業追跡操作と作業追跡のカスタマイズに適用される操作とオブジェクトの制限を定義します。 選択したオブジェクトに対して指定されたハード制限に加えて、特定の実用的な制限が適用されます。 作業項目の種類 (WIT) をカスタマイズする場合は、オブジェクトに対する制限を考慮してください。
作業項目とクエリ
作業項目を定義する場合、またはクエリを実行する場合は、次の操作制限が適用されます。
Object | なし |
---|---|
作業項目に追加された添付ファイル | 100 |
添付ファイルのサイズ | 60 MB |
長いテキスト フィールド | 1 M 文字 |
クエリ実行時間 | 30 秒 |
Query results | 20,000 アイテム |
クエリの長さ | 32,000 文字 |
フォルダーの下の共有クエリ | 999 個のクエリ |
作業項目に割り当てられた作業項目リンク | 1,000 |
作業項目に割り当てられた作業項目タグ | 100 |
作業項目のリビジョン (REST API) | 10,000 |
プロジェクトごとのお気に入りのクエリ | 200 個のクエリ |
Azure DevOps Services 用 REST API を介して行われた更新については、作業項目のリビジョン制限 10,000 が適用されます。 この制限により、REST API からの更新は制限されますが、Web ポータルからの更新は影響を受けません。
Object | なし |
---|---|
長いテキスト フィールド | 1 M 文字 |
作業項目に割り当てられた作業項目タグ | 100 |
作業項目に割り当てられた作業項目リンク | 1,000 |
作業項目に追加された添付ファイル | 100 |
添付ファイルのサイズ | 4 MB から 2 GB |
クエリ実行時間 | 6 分 |
Query results | 20,000 アイテム |
クエリの長さ | 32,000 文字 |
フォルダーの下の共有クエリ | 999 個のクエリ |
プロジェクトごとのお気に入りのクエリ | 200 個のクエリ |
既定の添付ファイルの最大サイズは 4 MB です。 最大サイズ 2 GB まで変更できます。
クエリのパフォーマンスを向上させるには、「 クエリの定義/ベスト プラクティスを参照してください。
バックログ、ボード、ダッシュボード、チーム
チーム、作業項目タグ、バックログ、ボードを操作する場合は、次の操作の表示とオブジェクトの制限が適用されます。
ユーザー インターフェイス | なし |
---|---|
バックログ | 10,000 個の作業項目 |
Boards | 1,000 枚のカード ( Proposed および Completed ワークフロー状態カテゴリのカードを除く) |
タスクボード | 1,000 個のタスク |
区分パス | プロジェクトあたり 10,000 |
エリア パスの深さ | 14 |
チームごとのエリア パス | 300 |
繰り返しパス | プロジェクトあたり 10,000 |
反復パスの深さ | 14 |
チームごとのイテレーション パス | 300 |
プロジェクト ダッシュボード | プロジェクトあたり 500 |
チーム ダッシュボード | チームあたり 500 |
Teams | プロジェクトあたり 5,000 |
作業項目のタグ | 組織またはコレクションあたり 150,000 個のタグ定義 |
プロジェクトごとの配信計画 | 1,000 |
作業項目の種類ごとのテンプレート | 100 |
各バックログには、最大 10,000 個の作業項目を表示できます。 これは、定義できる作業項目の数の制限ではなく、バックログが表示できる内容に関する制限です。 バックログがこの制限を超える場合は、チームを追加し、一部の作業項目を他のチームのバックログに移動することを検討してください。
追加メモ:
- 変更日が 1 年を超えると、完了または終了した作業項目はバックログとボードに表示されません。 これらの項目の一覧は、引き続きクエリを使用して表示することができます。 バックログまたはボードに表示する場合は、表示用のクロックをリセットする小さな変更を行うことができます。
- 同じ型のバックログ項目を入れ子にしないでください。 詳細については、「 修正の並べ替えと入れ子の問題を参照してください。
- 複数のチームに同じエリア パスを割り当てないようにします。 詳細については、「 マルチチーム ボード ビューの制限を参照してください。
- 既定では、作業項目の制限は、最初は値を小さくするように構成されている可能性があります。
チーム、作業項目タグ、バックログ、ボードを操作する場合は、次の操作制限が適用されます。 既定と最大の制限。
ユーザー インターフェイス | なし |
---|---|
バックログ | 999 個の作業項目 |
Boards | 400 枚のカード |
プロジェクトごとのダッシュボード | 500 |
タスクボード | 800 個の作業項目 |
Teams | プロジェクトあたり 5,000 |
作業項目のタグ | プロジェクトあたり 150,000 個のタグ定義 |
作業項目の種類ごとのテンプレート | 100 |
各バックログには、最大 999 個の作業項目を表示できます。 バックログがこの制限を超える場合は、チームを追加し、一部の作業項目を他のチームのバックログに移動することを検討してください。
追加メモ:
- 同じ型のバックログ項目を入れ子にしないでください。 詳細については、「 修正の並べ替えと入れ子の問題を参照してください。
- 複数のチームに同じエリア パスを割り当てないようにします。 詳細については、「 マルチチーム ボード ビューの制限を参照してください。
オンプレミスの XML プロセス モデルでは、ProcessConfiguration.xml ファイルを編集することで、バックログとタスクボードの制限を変更できます。 詳細については、 Process 構成 XML 要素リファレンスを参照してください。
プロジェクト
Azure DevOps Services では、各組織は 1 組織あたり 1000 プロジェクトに制限され、以前の制限である 300 プロジェクトを超える増加となります。
Note
300 を超えるプロジェクトでは、Visual Studio からプロジェクトに接続するなど、特定のエクスペリエンスが低下し始める可能性があります。 オンプレミスの Azure DevOps Server の場合、プロジェクトの数にハード制限はありません。 ただし、プロジェクトの数が 300 に近づくと、パフォーマンスの問題が発生する可能性があります。 オンプレミスコレクションを Azure DevOps Services に移行する予定の場合は、最大 1,000 プロジェクトの上限を確認する必要があります。 コレクションに 1,000 を超えるプロジェクトがある場合は、コレクションを分割するか、古いプロジェクトを削除する必要があります。
詳細については、「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 MB | 60 MB |
Hosted XML プロセス モデルの追加の制限と準拠要件については、「 ホスト型 XML を使用する場合のプロセスのカスタマイズを参照してください。
Note
Hosted XML プロセス モデルでは、すべての WIT で指定されたすべてのグローバル リストに対して約合計 10,000 項目を定義できます。
次の表に、継承およびオンプレミスの 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 項目を定義できます。
実際の制限
パフォーマンスの問題を最小限に抑えるために、次のガイダンスを検討することをお勧めします。
- 定義するユーザー設定フィールドの数を最小限に抑えます。 すべてのユーザー設定フィールドは、プロセス、コレクション、または組織で許可される合計に影響します。 異なる WIT 内の同じフィールドに対して異なる動作を指定できることに注意してください。 つまり、さまざまなルール、選択リストなどを指定できます。
- WIT に対して定義する規則の数を最小限に抑えます。 1 つの WIT に対し複数のルールを作成できますが、ルールの追加は、ユーザーが作業項目を追加したり変更するときにパフォーマンスに悪影響を与える可能性があります。 ユーザーが作業項目を保存すると、その作業項目の種類のフィールドに関連付けられているすべてのルールが検証されます。 特定の条件下では、ルールの検証式が複雑になり SQL で評価できません。
- 定義するカスタム WIT の数を最小限に抑えましょう。
- 定義するユーザー設定フィールドの数を最小限に抑えます。 すべてのユーザー設定フィールドは、プロセス、コレクション、または組織で許可される合計に影響します。 異なる WIT 内の同じフィールドに対して異なる動作を指定できることに注意してください。 つまり、さまざまなルール、選択リストなどを指定できます。
- WIT に対して定義する規則の数を最小限に抑えます。 1 つの WIT に対し複数のルールを作成できますが、ルールの追加は、ユーザーが作業項目を追加したり変更するときにパフォーマンスに悪影響を与える可能性があります。 ユーザーが作業項目を保存すると、その作業項目の種類のフィールドに関連付けられているすべてのルールが検証されます。 特定の条件下では、ルールの検証式が複雑になり SQL で評価できません。
- 定義するカスタム WIT の数を最小限に抑えましょう。
- 定義するレポート可能フィールドの数を最小限に抑えます。 レポート可能フィールドは、データ ウェアハウスのパフォーマンスに影響します。
Note
作業項目ルールの検証が SQL 制限を超えています: 作業項目が作成または更新されるたびに検証するために、プロジェクトごとに 1 つの SQL 式が定義されます。 この式は、プロジェクトに定義されているすべての作業項目の種類に対して指定するルールの数に合わせて増加します。 フィールドに対して指定された動作修飾子ごとに、サブ式の数が増加します。 入れ子になったルール(遷移にのみ適用されるルール、または他のフィールドの値に基づいて条件付けされるルール)により、IF ステートメントにより多くの条件が追加されます。 式が特定のサイズまたは複雑さに達すると、SQL ではそれ以上評価できないため、エラーが発生します。 一部の WIT を削除するか、一部のルールを削除すると、エラーが解決される可能性があります。
転送率の制限
コストを削減し、スケーラビリティとパフォーマンスを向上させるために、Azure DevOps Services は、多くのサービスとしてのソフトウェア ソリューションと同様に、マルチテナントを使用します。 優れたパフォーマンスを確保し、停止の可能性を減らすために、Azure DevOps Services では、個人が使用できるリソースと、特定のコマンドに対して行うことができる要求の数が制限されます。 これらの制限を超えると、後続の要求が遅延またはブロックされる可能性があります。
ほとんどのレート制限は、REST API 呼び出しまたは最適化されていないクエリを通じて達成されます。 詳細については、次の記事をご覧ください。
制限の移行とインポート
オンプレミスから Azure DevOps Services への移行を決定する場合、発生する可能性のあるサイズ制限がいくつかあります。 その制限は以下のとおりです:
- データベース サイズが推奨サイズを超えています
- 最大テーブル サイズが推奨サイズを超えています
- データベースメタデータのサイズがサポートされているサイズを超えています
詳細については、「 Azure DevOps Server から Azure DevOps Services にデータを移行する と インポートと移行のエラーのトラブルシューティングを参照してください。