工作追蹤、處理序和專案限制

Azure DevOps 服務 |Azure DevOps Server |Azure DevOps Server 2022

本文說明 Azure DevOps 對工作追蹤作業與自訂設定的營運與物件限制。 一些實際限制也適用。 當您自定義工作專案類型 (WIT) 時,請考慮這些限制。

提示

使用 物件限制追蹤器 ,即時檢視貴組織在所有限制類別中的資源使用情況。 欲了解更多資訊,請參閱Azure DevOps 中的 Introducing Object Limit Tracker。

工作項目和查詢

下列限制適用於工作專案和查詢定義。

物件 限制
每個工作專案的附件 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 更新,不影響透過網頁入口網站進行的更新。 如果你透過 API 自動化工作項目更新且遇到這個限制,建議考慮建立一個新的工作項目來持續追蹤,而不是更新現有的。

當你達到極限時會發生什麼:

  • 查詢執行時間: 查詢會停止並回傳逾時錯誤。 加入更具體的過濾條件或日期範圍以縮小範圍。
  • 查詢結果: 結果被截斷為 20,000 件,且不會顯示錯誤。 細化你的篩選條件,或將查詢拆分成多個儲存的查詢。
  • 附件尺寸: 上傳時附件會被拒絕並顯示錯誤訊息。 在安裝前先壓縮或分割檔案。
  • 工作項目連結: 當新連結達到上限時會被封鎖。 考慮整合相關連結或存檔舊作品。
物件 限制
長文字欄位 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,特定於團隊,用於追蹤團隊特定的指標和數據
每個專案的團隊 5,000
每個工作專案的工作專案標籤 100
工作項目標籤與拉取請求標籤名稱,依組織或集合 合計15萬
每個專案的交付計劃 1,500
每個工作專案類型的範本 100

*每個待辦專案最多可以顯示 10,000 個工作專案,但您可以定義的工作專案數目沒有特定限制。 如果您的待辦專案超過 10,000 個專案,請考慮新增小組,並將一些工作專案移至新小組的待辦專案。

當你達到極限時會發生什麼:

  • 待辦清單顯示: 超出顯示限制的工作項目會被隱藏在待辦清單中,但不會被刪除。 使用查詢工具來尋找並管理隱藏物品。
  • 棋盤卡: 超出限制的牌則從棋盤上隱藏。 提案與完成狀態類別的項目不計入1,000張卡片的限制。
  • 儀表板限制: 一旦達到限制,就無法建立新的儀表板。 檢視並移除未使用的儀表板以釋放空間。

提示

如果你已經接近儀表板上限,請採取以下措施來減少數量。

  • 檢查最後存取日期或與團隊成員確認,然後移除重複或未使用的儀表板。
  • 匯出資料,然後封存舊儀表板。
  • 透過將更多小工具新增至儀表板,合併和合併類似的儀表板。

其他考慮

  • 如果待辦事項和公告板的 變更日期 超過一年,則不會顯示已完成或已結案的工作項目。 這種行為是預期中的,不是錯誤。 你仍然可以透過查詢找到這些工作項目。 要讓工作項目重新出現在待辦清單或看板上,請進行任何小幅更新以重置其 變更日期 ——例如新增註解或更新欄位值。
  • 請避免嵌套相同類型的待辦專案。 如需詳細資訊,請參閱 修正重新排序和巢狀問題。
  • 避免將相同的區域路徑指派給多個小組。 如需詳細資訊,請參閱 多小組面板檢視的限制。

下列作業顯示和物件限制適用於小組、工作專案標籤、待辦專案和面板。

元件 限制
待辦專案* 999 個工作專案
Boards 400 張卡片
每個專案的儀表板 500
任務板 800 個工作項目
每個專案的團隊 5,000
工作項目標籤與拉取請求標籤名稱,依組織或集合 合計15萬
每個工作專案的工作專案標籤 100
每個工作專案類型的範本 100

*每個待辦專案最多可顯示 999 個工作專案。 如果您的待辦專案超過此限制,請考慮建立新的小組,並將部分工作專案移至新小組的待辦專案。

其他考慮

GitHub 整合

如果你整合專案與 GitHub,以下限制適用。

整合 限制
Azure Boards web UI 每個連線有 2,000 個連接的 GitHub 倉庫
Azure Boards API* 每個連線有 2,000 個連接的 GitHub 倉庫

*更多資訊請參見GitHub Connections - 取得GitHub Connections。

當你達到極限時會發生什麼: 當連線達到儲存庫上限時,你就不能再往該連線新增更多儲存庫。 建立一個新的 GitHub 連結以新增更多儲存庫。

專案

Azure DevOps Services 限制每個組織最多 1,000 個專案。 當你專案超過 300 個時,某些體驗,例如從 Visual Studio 連接專案,可能會變得更差。 如果你在一個有許多專案的組織中遇到績效問題,可以考慮整合專案或將工作分散到多個組織。

對於本地的 Azure DevOps Server,專案數量沒有硬性限制,但當專案數量接近 300 時,可能會出現效能問題。 某些體驗,例如從 Visual Studio 連接專案,可能會退化。

遷移至 Azure DevOps Services 時,專案數量上限為 1,000 個。 如果您的集合超過此限制,請分割集合或刪除較舊的專案。 欲了解更多資訊,請參閱 將資料從Azure DevOps Server遷移至Azure DevOps服務。

流程自定義

你能為一個程序定義物件數量是有限制的。 如需詳細資訊,請參閱 自定義您的工作追蹤體驗。

下表列出您可以為繼承和託管 XML 進程模型定義的物件數目上限。 實際限制也可能適用。

物件 繼承 托管的 XML
每個組織的處理程序數 256 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 個專案。

實際限制

即使你在硬物件限制內,隨著自訂物件數量增加,效能也會下降。 以下指引代表 Microsoft 建議的可預測效能運作範圍。 為了減少效能問題,請遵循以下指引:

  • 限制您定義的自定義欄位數目。 所有自定義欄位都會參與進程、集合或組織所允許的總計。 您可以針對不同 WIT 中的相同欄位指定不同的行為,例如規則和選擇清單。

  • 限制您為 WIT 定義的規則數目。 雖然您可以為 WIT 建立多個規則,但當使用者新增或修改工作專案時,其他規則可能會對效能造成負面影響。

  • 限制您定義的自定義 WIT 數目。

  • 避免使用與多個建構綁定的長壽命工作物品。 工作項目的「 內建於建構 」連結越多,就越可能看到「內建建置連結無法讀取」錯誤。 除了使用較短壽命的工作項目外,我們建議考慮關閉部分管線的「自動連結本執行中包含的工作項目」,或使用 Rest API 移除不再需要的建置連結。

  • 限制您定義的可報告欄位數目。 可報告欄位可能會影響數據倉儲的效能。

工作項目規則驗證超過 SQL 限制

每個專案都會定義單一 SQL 運算式,以便在建立或更新工作專案時驗證工作專案。 此表達式會隨著專案中所有工作項目類型所指定的規則數目而成長。

欄位的每個行為限定詞都會增加子運算式的數目。 巢狀規則、僅適用於轉換的規則,或以另一個欄位值為條件的規則,會將更多條件新增至 IF 陳述式。

當使用者儲存工作專案時,系統會驗證與該工作項目類型欄位相關聯的所有規則。 一旦表達式達到一定大小或複雜度,SQL 就無法有效評估,可能會產生錯誤。 若要解決此錯誤,請移除某些 WIT 或排除某些規則。

提示

如果使用者在儲存工作項目時發現錯誤,且你自訂了大量規則,請檢視專案中所有 WIT 的規則數量。 減少條件規則(例如僅在狀態轉換期間適用或依賴其他域值的規則)對降低表達式複雜度影響最大。

速率限制

Azure DevOps 服務,像許多軟體即服務解決方案一樣,利用多租戶制來降低成本並提升可擴展性與效能。 為了確保良好效能並降低故障風險,Azure DevOps Services 限制個人可使用的資源及對特定指令的請求次數。 當使用者超過這些限制時,服務可能會延遲或阻擋後續的請求。

大部分速率限制都是透過 REST API 呼叫或非優化查詢來達到。 如需詳細資訊,請參閱 速率限制 和 避免達到速率限制的最佳實務。

移轉和匯入限制

當你從本地的 Azure DevOps Server 遷移到 Azure DevOps Services 時,你的集合必須符合以下大小要求:

量值 建議的限制
資料庫總大小 150 GB
最大個人表格 30 GB
資料庫元資料大小 2 GB

若你的集合超過這些限制,遷移驗證會在傳輸資料前失敗。 要解決此問題,請參閱「 故障排除匯入與遷移錯誤 」,其中有資料清理與收藏拆分等選項。 完整遷移過程請參閱 Migrate data from Azure DevOps Server to Azure DevOps Services.