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