如何在C#中实现WorkItem创建的事务回滚机制？

针对10万级WorkItem的迁移场景，DevOps/TFS本身没有数据库那样的全局事务支持，得靠补偿机制+状态控制实现类似回滚的效果，以下是几个可行的落地方案：

方案1：草稿态预创建 + 批量激活/清理 #

这是最直接的思路：

• 迁移时，先把所有WorkItem以草稿/待确认的状态创建（比如用系统自带的"New"状态，或添加专属标记标签）
• 全程捕获异常，一旦出错，调用API批量删除所有已创建的草稿WorkItem
• 当所有WorkItem都成功创建完成后，再批量更新它们的状态为正式激活状态（或移除标记标签）

核心代码示例 #

using Microsoft.TeamFoundation.WorkItemTracking.WebApi;
using Microsoft.TeamFoundation.WorkItemTracking.WebApi.Models;
using Microsoft.VisualStudio.Services.Common;

// 初始化DevOps客户端
var connection = new VssConnection(new Uri("https://dev.azure.com/你的组织"), new VssBasicCredential("", "你的PAT令牌"));
var workItemClient = connection.GetClient<WorkItemTrackingHttpClient>();

List<int> createdWorkItemIds = new List<int>();
try
{
    foreach (var sourceWorkItem in 源WorkItem列表)
    {
        // 创建草稿态WorkItem（以Bug为例，添加"MigrationDraft"标签标记）
        var patchDocument = new JsonPatchDocument
        {
            new JsonPatchOperation()
            {
                Operation = Operation.Add,
                Path = "/fields/System.Title",
                Value = sourceWorkItem.Title
            },
            new JsonPatchOperation()
            {
                Operation = Operation.Add,
                Path = "/fields/System.State",
                Value = "New"
            },
            new JsonPatchOperation()
            {
                Operation = Operation.Add,
                Path = "/fields/System.Tags",
                Value = "MigrationDraft"
            }
        };

        var createdWorkItem = await workItemClient.CreateWorkItemAsync(patchDocument, "你的项目", "Bug");
        createdWorkItemIds.Add(createdWorkItem.Id.Value);
    }

    // 全部创建完成，批量移除草稿标签
    foreach (var id in createdWorkItemIds)
    {
        var updatePatch = new JsonPatchDocument
        {
            new JsonPatchOperation()
            {
                Operation = Operation.Remove,
                Path = "/fields/System.Tags",
                Value = "MigrationDraft"
            }
        };
        await workItemClient.UpdateWorkItemAsync(updatePatch, id);
    }
}
catch (Exception ex)
{
    // 发生异常，批量删除已创建的草稿WorkItem
    foreach (var id in createdWorkItemIds)
    {
        try
        {
            await workItemClient.DeleteWorkItemAsync(id, destroy: true); // destroy:true彻底删除，否则进回收站
        }
        catch { /* 忽略删除失败，避免连锁错误 */ }
    }
    throw; // 抛出原异常便于排查
}

方案2：分批次处理 + 检查点记录 #

10万个WorkItem一次性处理风险太高，建议拆分成小批次（比如每100个一批），同时记录检查点：

• 每处理完一批，就把该批次的WorkItem ID和处理状态写入本地文件或数据库
• 如果某一批处理失败，先删除当前批次已创建的WorkItem，然后从上个检查点重新开始
• 全部批次处理完成后，可统一做状态激活（可选）

这种方式既能降低单次操作的压力，也能避免一次失败导致前功尽弃，回滚范围仅限定在当前出错的批次。

方案3：批量API补偿机制 #

Azure DevOps的Batch API可一次提交多个WorkItem操作，但不支持原子回滚（成功的操作不会因后续失败撤销），需手动做补偿：

• 把一批WorkItem的创建请求打包成Batch请求发送
• 如果Batch返回部分失败，遍历响应结果找出已成功创建的WorkItem ID，逐个删除
• 重新处理失败的WorkItem，或终止流程

注意事项 #

• 针对10万级数据，一定要做好限流和重试，避免触发API速率限制（可借助Polly库实现重试逻辑）
• 删除WorkItem时，destroy: true会彻底删除，否则仅移入回收站，需后续手动清理
• 迁移时间跨度大时，定期备份检查点数据，防止程序崩溃丢失进度

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