Azure DevOps组织多项目合并为单个大项目的可行性咨询

你描述的规模完全可以在单个Azure DevOps项目中稳定运行，我所在的运维团队有同场景的落地经验，相关参考信息如下：

已验证的规模基线 #

我们运维的同类型内部支持场景单Azure DevOps项目，已稳定运行3年，核心数据如下：

• 累计工作项总量120万+，每周新增工作项峰值1.3万条
• 总用户数2300+，其中处理人员270名，其余均为请求方
• 团队总数140个
• 日常查询平均响应时间在800ms-1.5s区间，未出现过性能故障

你关注的查询性能优化建议 #

你担心的全量检索问题完全可以通过配置规避，不需要承担额外的改造负担：

• 合并后给每个原业务团队配置独立的区域路径，所有工作项按所属团队分配对应区域路径，处理人员的日常查询默认加上「所属区域路径」过滤条件，实际检索的数据量级和合并前完全一致，不会出现全量扫描每周1万条数据的情况
• 普通请求方的提交和查询权限默认限制在自身所属区域路径下，进一步缩小请求的检索范围
• 你规划的归档方案可行，但可以适当拉长周期：Azure DevOps会自动将关闭超过6个月的工作项划入冷存储层级，日常高频查询不会主动检索这部分数据，你可以将归档周期调整为12-18个月，降低运维成本

合并操作的注意事项 #

• 提前将4套流程模板的字段、工作项类型、状态流转规则对齐到主模板，避免迁移后出现数据不兼容问题
• 迁移工作项时批量打上原项目归属标签，同时完成区域路径分配，方便后续追溯和过滤
• 合并后可以按需开启工作项的全文检索功能，不会对基线性能产生明显影响

内容的提问来源于stack exchange，提问作者Pawel B