最佳集成做法
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 的更新，但 Web 门户中的更新不会受到影响。
优化查询
优化查询以返回少量结果。 复杂的条件和筛选器可能会导致长时间运行的查询。 将查询执行时间保持在 30 秒以下，以避免阈值失败。
查询性能提示
- 尽可能将日期或范围限制子句放置在查询顶部附近。
- 减少使用 Ever 运算符的子句数。
- 减少使用 Contains 运算符的子句数，但 Tags 除外。
- 如果可用， 请使用 Contains Words 运算符。
- 不要对长文本字段使用 Contains 运算符，因为它很昂贵。
- 如果可能，请避免使用“<>”而不是运算符。
- 避免对 大型组使用 In Group 运算符。
- 尽量减少 Or 运算符的数量，并确保在使用之前仍具有顶级范围。
- 避免在 In Group 运算符和区域或迭代路径之间使用 OR 子句。
- 尽可能减少实现目标的总体子句数。
- 尽可能避免对核心字段（如 ID）以外的任何内容进行排序。
- 如果要对自定义字段进行排序，请在筛选器中使用自定义字段。
- 如果可能，请指定项目。 否则，查询的范围限定为整个集合，并且可能需要比它所需的时间长得多。 取消检查查询编辑器的“跨右上角的项目进行查询”。
在项目间查询
- 指定查询需要跨项目搜索时要查找的项目。
- 尽可能使用标记而不是关键字 (keyword)，除非搜索字符串的部分文本。
正常处理故障
当资源限制或利用率频率超过限制阈值时，汇报和查询会失败。 例如，运行时间超过 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# 示例。