最佳整合作法

  • 發行項

Azure DevOps Services

服務之間的工具和整合可提升 Azure DevOps Services 的效率。 如果您不小心，自動化工具可以無法控制執行高比率的要求。 要求會導致 Azure DevOps 對貴組織強制執行 速率限制 。 為了協助降低達到速率限制的風險，當您使用 REST API 與 Azure DevOps 整合時，請遵循這些最佳做法。

僅推送可採取動作的工作專案

只有將可採取動作的專案推送到 Azure DevOps 中，您的小組計劃在未來參與或解決。 將工作專案保留在 Azure DevOps 中，直到必要為止。 例如，請勿嘗試將遙測數據儲存在 Azure DevOps 中。

維護您自己的數據存放區

請勿將工作專案新增至 Azure DevOps，以便將它們全部放在單一位置。 Azure DevOps Services 並非設計為數據記憶體服務。 維護您自己的數據存放區。

批處理您的變更

執行單一作業的速度很慢且昂貴，這是效能問題和速率限制的主要原因。 將您的變更批處理成單一呼叫。 如需詳細資訊，請參閱我們的批次檔和範例程序代碼。

限制您的修訂

單一工作專案的許多修訂都會造成膨脹，並造成效能問題。 建議您執行下列工作：

  • 藉由批處理欄位變更來減少更新。 不要一次只更新一個字段。
  • 如果您有多個工作項目的變更，請將這些變更批處理成單一動作。
  • 將修訂數目保持在最小值，以避免修訂限制。

注意

透過 REST API 進行的更新，工作專案修訂限制為 10,000 有效。 此限制會限制來自 REST API 的更新，但入口網站中的更新不會受到影響。

最佳化查詢

將您的查詢優化，以傳回少量的結果。 複雜的條件和篩選可能會導致長時間執行的查詢。 將您的查詢運行時間保持在 30 秒以內，以避免閾值失敗。

查詢效能祕訣

  • 盡可能將日期或範圍限制子句放在查詢頂端附近。
  • 減少使用 Ever 運算子句數目。
  • 減少使用 Contains 運算子的子句數目，但 Tags 除外。
    • 當可用時，請使用 Contains Words 運算符。
    • 請勿 在長文字欄位上使用 Contains 運算符，因為它很昂貴。
  • 盡可能避免 『<>' 和 not 運算子。
  • 避免針對大型群組使用 In Group 運算子。
  • 將 Or 運算子的數目降到最低，並確定在使用之前仍具有最上層範圍。
  • 避免在 In Group 運算子與區域或反覆專案路徑之間使用 OR 子句。
  • 盡可能減少達成目標的整體子句數目。
  • 盡可能避免排序核心欄位以外的任何專案，例如 ID。
  • 如果您想要排序自定義欄位，請在篩選中使用自訂欄位。
  • 可能的話，請指定專案。 否則，查詢的範圍會限定於整個集合，而且可能需要比它所需的時間長得多。 取消核取查詢編輯器的 [跨項目查詢]。

跨專案查詢

  • 如果查詢需要跨項目搜尋，請指定您要尋找的專案。
  • 除非您搜尋字串的部分文字，否則請盡可能使用標籤，而不是關鍵詞。

正常處理失敗

當資源限制或使用率頻率超過限制閾值時，更新 和查詢就會失敗。 例如，執行超過 30 秒的查詢會傳回下列錯誤：

VS402335: The timeout period (30 seconds) elapsed prior to completion of the query or the server is not responding.

當您取用 REST API 時，請務必設計程式代碼以適當地處理失敗。

盡可能限制每個工作項目的連結數目，以避免強制執行連結限制。

重要

我們計劃在不久的將來強制執行工作專案修訂和連結限制。 這些限制取決於效能監視和客戶意見反應。

請勿使用查詢來報告

使用查詢和個別 取得工作專案 呼叫是取得貴組織強制執行速率限制的最上層方式。 請勿執行查詢以傳回大型工作項目清單。 請改用報告 工作項目連結 和 工作專案修訂 REST API。

如需詳細資訊，請參閱 GitHub 上的 C# 範例。