作業の追跡、処理、およびプロジェクトの制限
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 workflow 状態カテゴリのカードを除く) |
| タスクボード | 1,000 個のタスク |
| 区分パス | プロジェクトあたり 10,000 |
| エリア パスの深さ | 14 |
| チームごとのエリア パス | 300 |
| 繰り返しパス | プロジェクトあたり 10,000 |
| 反復パスの深さ | 14 |
| チームごとのイテレーション パス | 300 |
| プロジェクト ダッシュボード | プロジェクトあたり 500。 プロジェクト レベルでアクセスでき、プロジェクトにアクセスできるすべてのユーザーが使用できます。 |
| チーム ダッシュボード | チームあたり 500。 チーム固有で、チーム固有のメトリックとデータの追跡に使用されます。 |
| Teams | プロジェクトあたり 5,000 |
| 作業項目のタグ | 組織またはコレクションあたり 150,000 個のタグ定義 |
| プロジェクトごとの配信計画 | 1,000 |
| 作業項目の種類ごとのテンプレート | 100 |
各バックログには、最大 10,000 個の作業項目を表示できます。 この制限は、特定の制限がないため、定義できる作業項目の数ではなく、バックログに表示できる内容に適用されます。 バックログがこの制限を超える場合は、チームを追加し、いくつかの作業項目を新しいチームのバックログに移動することを検討してください。
ヒント
ダッシュボードの制限に近づいている場合は、ダッシュボードを管理およびクリーンアップするための次の手順を参照してください。
- 使用状況を確認する: 使用されなくなったダッシュボードまたは重複しているダッシュボードを特定します。 これを行うには、最後にアクセスした日付を確認するか、チーム メンバーに相談します。
- ダッシュボードを統合する: 類似のダッシュボードを組み合わせて合計数を減らします。 これを行うには、1 つのダッシュボードに複数のウィジェットを追加します。
- 古いダッシュボードをアーカイブする: 特定のダッシュボードが不要になったが、データを保持したい場合は、データのエクスポートとダッシュボードのアーカイブを検討してください。
- オブジェクト制限トラッカー機能を使用する: ダッシュボードを含むリソースの使用状況をリアルタイムで可視化します。 この機能は、制限 非アクティブに管理し、潜在的な問題を回避するのに役立ちます。
その他の注意事項:
- Changed Date が 1 年以上経過すると、完了または終了した作業項目はバックログやボードに表示されません。 これらの項目の一覧は、引き続きクエリを使用して表示することができます。 バックログまたはボードに表示するには、表示クロックをリセットするために小さな変更を行います。
- 同じ型のバックログ項目を入れ子にしないでください。 詳細については、「 修正の並べ替えと入れ子の問題を参照してください。
- 複数のチームに同じエリア パスを割り当てないようにします。 詳細については、「 マルチチーム ボード ビューの制限を参照してください。
- 既定では、作業項目の制限は最初は小さい値に設定される場合があります。
チーム、作業項目タグ、バックログ、ボードを使用する場合は、次の操作制限が適用されます。 既定と最大の制限。
| ユーザー インターフェイス | なし |
|---|---|
| バックログ | 999 個の作業項目 |
| Boards | 400 枚のカード |
| プロジェクトごとのダッシュボード | 500 |
| タスクボード | 800 個の作業項目 |
| Teams | プロジェクトあたり 5,000 |
| 作業項目のタグ | プロジェクトあたり 150,000 個のタグ定義 |
| 作業項目の種類ごとのテンプレート | 100 |
各バックログには、最大 999 個の作業項目を表示できます。 バックログがこの制限を超える場合は、チームを作成し、作業項目の一部を新しいチームのバックログに移動することを検討してください。
その他の注意事項:
- 同じ型のバックログ項目を入れ子にしないでください。 詳細については、「 修正の並べ替えと入れ子の問題を参照してください。
- 複数のチームに同じエリア パスを割り当てないようにします。 詳細については、「 マルチチーム ボード ビューの制限を参照してください。
オンプレミスの XML プロセス モデルでは、 ProcessConfiguration.xml ファイルを編集することで、バックログとタスクボードの制限を変更できます。 詳細については、 Process 構成 XML 要素リファレンスを参照してください。
プロジェクト
Azure DevOps Services では、各組織は 1 組織あたり 1,000 プロジェクトに制限され、以前の制限である 300 プロジェクトを上回ります。
Note
300 を超えるプロジェクトでは、Visual Studio からプロジェクトに接続するなどの特定のエクスペリエンスが低下する可能性があります。 オンプレミスの Azure DevOps Server の場合、ハード制限はありませんが、プロジェクトの数が 300 に近づくとパフォーマンスの問題が発生する可能性があります。 Azure DevOps Services に移行する場合は、最大 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 |
| 作業項目の種類に対して定義されたアクション | 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 に対して定義するルールの数を制限します。 WIT に対して複数のルールを作成できますが、他のルールは、ユーザーが作業項目を追加または変更するときにパフォーマンスに悪影響を与える可能性があります。 ユーザーが作業項目を保存すると、その作業項目タイプのフィールドに関連付けられているすべてのルールが検証されます。 場合によっては、規則の検証式が複雑すぎて SQL で効率的に評価できない場合があります。
- 定義するカスタム WIT の数を制限します。
- 定義するユーザー設定フィールドの数を制限します。 すべてのユーザー設定フィールドは、プロセス、コレクション、または組織で許可される合計に影響します。 異なる WIT の同じフィールドに対して、ルールや候補リストなどのさまざまな動作を指定できます。
- WIT に対して定義するルールの数を制限します。 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 にデータを移行する と インポートと移行のエラーのトラブルシューティングを参照してください。