工作追蹤、處理序和專案限制
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
本文定義工作追蹤作業和工作追蹤自定義的作業和物件限制。 除了特定物件的指定硬性限制之外，還適用一些實際限制。 當您自定義工作項目類型 （WIT）時，請考慮對 物件所設定的限制。
工作項目和查詢
當您定義工作項目或執行查詢時，請記住下列作業限制：
| Object | 限制 |
|---|---|
| 新增至工作專案的附件 | 100 |
| 附件大小 | 60 MB |
| 長文字欄位 | 1-M 個字元 |
| 查詢執行時間 | 30 秒 |
| 查詢結果 | 20,000 個專案 |
| 查詢長度 | 32,000 個字元 |
| 資料夾下的共享查詢 | 999 個查詢 |
| 指派給工作專案的工作項目連結 | 1,000 |
| 指派給工作專案的工作項目標籤 | 100 |
| 工作專案修訂 （REST API） | 10,000 |
| 每個專案的我的最愛查詢 | 200 個查詢 |
Azure DevOps Services 的 REST API 會強制執行工作專案修訂限制 10,000 個更新。 此限制會限制透過 REST API 進行的更新，但入口網站中的更新不會受到影響。
| Object | 限制 |
|---|---|
| 長文字欄位 | 1-M 個字元 |
| 指派給工作專案的工作項目標籤 | 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 個 |
| 區域路徑深度 | 14 |
| 每個小組的區域路徑 | 300 |
| 反覆項目路徑 | 每個專案 10,000 個 |
| 反覆項目路徑深度 | 14 |
| 每個小組的反覆項目路徑 | 300 |
| 項目儀錶板 | 每個專案 500 個。 可在專案層級存取，以及具有專案存取權的任何人都可以使用。 |
| 小組儀錶板 | 每個小組 500 個。 專屬於小組，並用來追蹤小組特定的計量和數據。 |
| Teams | 每個專案 5,000 個 |
| 工作項目標籤 | 每個組織或集合 150,000 個標記定義 |
| 每個專案的傳遞計劃 | 1,000 |
| 每個工作專案類型的範本 | 100 |
每個待辦專案最多可以顯示10,000個工作專案。 此限制適用於待辦專案可以顯示的內容，不適用於您可以定義的工作項目數目，因為沒有特定的限制。 如果您的待辦項目超過此限制，請考慮新增小組，並將某些工作專案移至新小組的待辦專案。
提示
如果您即將接近儀錶板限制，請參閱下列步驟來管理和清除您的儀錶板：
- 檢閱使用方式： 識別不再使用或重複的儀錶板。 您可以藉由檢查上次存取的日期，或諮詢小組成員來執行此動作。
- 合併儀錶板： 合併類似的儀錶板以減少總數。 這可以藉由將多個小工具新增至單一儀錶板來完成。
- 封存舊的儀錶板： 如果不再需要某些儀錶板，但您想要保留數據，請考慮導出數據並封存儀錶板。
- 使用物件限制追蹤器功能： 提供資源的即時可見度，包括儀錶板。 這項功能可協助您 主動管理限制，並避免潛在的問題。
其他注意事項：
- 完成或關閉的工作專案一旦 變更日期 超過一年，就不會顯示在待辦專案和面板上。 您仍然可以使用查詢來列出這些專案。 若要讓它們顯示在待辦專案或面板上，請稍微變更以重設顯示時鐘。
- 請避免巢狀相同類型的待辦專案。 如需詳細資訊，請參閱 修正重新排序和巢狀問題。
- 避免將相同的區域路徑指派給多個小組。 如需詳細資訊，請參閱 多小組面板檢視的限制。
- 根據預設，工作專案限制一開始可能會設定為較低的值。
當您使用小組、工作專案標籤、待辦專案和面板時，適用下列作業限制。 預設和最大限制。
| 使用者介面 | 限制 |
|---|---|
| 積存 | 999 個工作專案 |
| Boards | 400 張卡片 |
| 每個項目的儀錶板 | 500 |
| 任務板 | 800 個工作專案 |
| Teams | 每個專案 5,000 個 |
| 工作項目標籤 | 每個專案 150,000 個標記定義 |
| 每個工作專案類型的範本 | 100 |
每個待辦專案最多可以顯示999個工作專案。 如果您的待辦項目超過此限制，請考慮建立小組，並將部分工作專案移至新小組的待辦專案。
其他注意事項：
- 請避免巢狀相同類型的待辦專案。 如需詳細資訊，請參閱 修正重新排序和巢狀問題。
- 避免將相同的區域路徑指派給多個小組。 如需詳細資訊，請參閱 多小組面板檢視的限制。
針對內部部署 XML 進程模型，您可以編輯 ProcessConfiguration.xml 檔案來修改待辦專案和工作面板限制。 如需詳細資訊，請參閱 處理組態 XML 元素參考。
專案
Azure DevOps Services 會將每個組織限制為每個組織 1,000 個專案，比先前限制的 300 個專案增加。
注意
超過 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 |
| 為組織或集合定義的 Picklist | 2048 | - |
| 為清單定義的挑選清單專案 | 2048 | 2048 |
| Picklist 專案字元長度 | 256 | - |
| 為工作項目類型定義的工作流程狀態 | 32 | 16 |
| 為工作項目類型定義的規則 | 1024 | 1024 |
| 針對工作項目類型定義的動作 | 1024 | 1024 |
| 為規則定義的動作 | 10 | 10 |
| 針對進程定義的組合待辦專案層級 | 5 | 5 |
| 為進程定義的類別 | - | 32 |
| 針對進程定義的全域清單 | - | 256 |
| 列出全域清單內定義的專案 | - | 1024 |
| 工作專案附件大小 | 60 MB | 60 MB |
如需託管 XML 進程模型的其他限制和一致性需求，請參閱 使用託管 XML 時自定義進程。
注意
針對裝載的 XML 進程模型，您可以在所有 WIT 中指定的所有全域清單中定義大約 10,000 個專案。
下表列出您可以為繼承和內部部署 XML 進程模型定義的物件數目上限。 雖然這些限制是硬性限制，但實際限制也可能適用。
| Object | 繼承 | 內部部署 XML |
|---|---|---|
| 您可以在組織中擁有的程式數目 | 64 | 64 |
| 為進程定義的工作項目類型 | 64 | 64 |
| 為集合定義的欄位 | 8192 | 1024 |
| 為進程定義的欄位 | 1024 | 1024 |
| 為工作項目類型定義的欄位 | 1024 | 1024 |
| 為集合定義的 Picklist | 1024 | N/A |
| 為清單定義的挑選清單專案 | 2048 | 2048 |
| Picklist 專案字元長度 | 256 | N/A |
| 為工作項目類型定義的工作流程狀態 | 32 | 16 |
| 為工作項目類型定義的規則 | 1024 | 1024 |
| 針對進程定義的組合待辦專案層級 | 5 | 5 |
| 為進程定義的類別 | N/A | 32 |
| 針對進程定義的全域清單 | N/A | 256 |
| 列出全域清單內定義的專案 | N/A | 1024 |
注意
針對內部部署 XML 進程模型，您可以針對所有 WIT 指定的所有全域清單定義大約 10K 個專案。
實際限制
若要將效能問題降到最低，建議您遵循下列指引：
- 限制您定義的自定義欄位數目。 所有自定義欄位都會參與進程、集合或組織所允許的總計。 您可以針對不同 WIT 中的相同欄位指定不同的行為，例如規則和選擇清單。
- 限制您為 WIT 定義的規則數目。 雖然您可以為 WIT 建立多個規則，但當使用者新增或修改工作專案時，其他規則可能會對效能造成負面影響。 當使用者儲存工作專案時，系統會驗證與該工作項目類型欄位相關聯的所有規則。 在某些情況下，規則驗證表達式可能太複雜，SQL 無法有效率地評估。
- 限制您定義的自定義 WIT 數目。
- 限制您定義的自定義欄位數目。 所有自定義欄位都會參與進程、集合或組織所允許的總計。 您可以針對不同 WIT 中的相同欄位指定不同的行為，例如規則和選擇清單。
- 限制您為 WIT 定義的規則數目。 雖然您可以為 WIT 建立多個規則，但當使用者新增或修改工作專案時，其他規則可能會對效能造成負面影響。 當使用者儲存工作專案時，系統會驗證與該工作項目類型欄位相關聯的所有規則。 在某些情況下，規則驗證表達式可能太複雜，SQL 無法有效率地評估。
- 限制您定義的自定義 WIT 數目。
- 限制您定義的可報告欄位數目。 可報告欄位可能會影響數據倉儲的效能。
注意
工作專案規則驗證超過 SQL 限制：每個專案都會定義單一 SQL 運算式，以在建立或更新工作專案時驗證工作專案。 此表達式會隨著專案中所有工作項目類型所指定的規則數目而成長。 欄位的每個行為限定元都會增加子表達式的數目。 巢狀規則、僅適用於轉換的規則，或條件為另一個字段值的規則會將更多條件新增至 IF 語句。 一旦表達式達到特定大小或複雜度，SQL 就無法再評估它併產生錯誤。 若要解決此錯誤，請移除某些 WIT 或排除某些規則。
速率限制
為了降低成本並增強延展性和效能，Azure DevOps Services 與許多軟體即服務解決方案一樣，會使用多租使用者。 為了確保良好的效能，並將中斷的風險降到最低，Azure DevOps Services 會限制個人可以取用的資源，以及他們可對特定命令提出的要求數目。 超過這些限制時，後續的要求可能會延遲或封鎖。
大部分速率限制都是透過 REST API 呼叫或非優化查詢來達到。 如需詳細資訊，請參閱速率限制和最佳做法（以避免達到速率限制）。
移轉和匯入限制
從內部部署移轉至 Azure DevOps Services 時，您可能會遇到數個大小限制，包括：
- 超過建議大小的資料庫大小
- 超過建議大小的最大數據表大小
- 超過支援大小的資料庫元數據大小
如需詳細資訊，請參閱 將數據從 Azure DevOps Server 遷移至 Azure DevOps Services ，以及 針對匯入和移轉錯誤進行疑難解答。