我可以在从 Visual Studio 签入时将 A TFS 2012 BUG 设置为自动完成吗？答案

【问题标题】：Can I set A TFS 2012 BUG to Done automatically upon check in from Visual Studio?我可以在从 Visual Studio 签入时将 A TFS 2012 BUG 设置为自动完成吗？
【发布时间】：2015-05-21 18:19:51
【问题描述】：

当您在 Visual Studio 2013/tfs2012 中签入与 A 任务相关联的工作时，您可以“关联”或“解决”该任务。将其设置为“解决”将自动将冲刺积压和看板板上的任务移动到“完成”。这很好，因为作为开发人员，您只需要使用正确的状态和状态进行签入即可:-)。

“错误”类型的工作项似乎不是这种情况 - 在这里我只能在 vs2013 中选择“关联”，然后我还需要手动输入网络访问并将错误设置为“完成”。所以我有点做同样的工作两次。

我能否在不自定义 TFS 工作项类型或过程模板的情况下将此错误状态设置为“已解决”，因为它现在与“任务”一起使用 - 以及如何？

【问题讨论】：

这可以使用警报（并通过创建将由 tfs 警报系统使用的肥皂服务）或使用服务器端插件来完成。其中任何一个对你来说都可行吗？
这是个好主意，但我想避免任何类型的“非开箱即用”tfs2012 功能。所以在这种情况下这对我不起作用。

标签： visual-studio tfs alm

【解决方案1】：

这绝对是可能的——我们对每个错误都使用“解决”（在敏捷模板下），因为它可以节省大量时间。在待定更改中，只需关联错误（输入其工作项 ID，或将错误拖放到待定更改的该区域），然后您可以“关联”或“解决”它。（之后发起者可以验证修复并关闭它）

我假设您使用的模板不提供此功能 - 因此，也许您可以将您的模板与标准敏捷模板进行比较，您可能会发现允许这种行为所需的调整。您使用的模板是否支持错误的“已解决”状态？也许它不见了？

如果只是您的错误模板跳过了“已解决”状态，那么重命名等效状态将是微不足道的（也许它只是没有被 UI 拾取，因为它没有正确命名或不正确组？）或使用 WIT 编辑器插入新状态。

【讨论】：

我们使用的是 SCRUM 2.1 模板，实际上我们在我的工作下选择了错误工作项，并且在从 vs2013 签入期间，只有“关联”到错误的选项 - 无法解决。您是否建议比较敏捷和 SCRUM 模板中的错误的工作项模板，以验证是否可以从 Visual Studio 过渡到已解决？我非常希望不要自定义 Tfs 以避免以后出现潜在的 Tfs 升级问题。
是的，这是我的猜测——听起来 Scrum 不支持“解决”状态，所以用户界面不允许您选择它。我理解您对保持模板“纯”（因此与未来兼容）的感受，但是像这样对工作项模板的更改通常非常安全（或者如果在未来升级中发生冲突，至少相对容易手动合并） .值得检查一个简单的调整是否可以解决问题。 IIRC 它是 TFS 电动工具扩展，可让您轻松地从服务器编辑工作项类型。
我注意到 PBI 和 BUG 都不支持在 Visual Studio 中签入期间设置为“已解决”的功能（至少在 SCRUM 2.1 模板中不支持）。然而，任务确实支持这一点（它们可以是“关联的”或“已解决的”）。所以我应该做的（为了不修改 WIT）本来是在我的 BUG 下创建一个任务，然后在签入时可以“解决”。实际上，您和@JustTFS 都帮助理解了这个问题。谢谢。

【解决方案2】：

在签入时设置错误确实不是一个好主意。编码人员是否验证完成的输出符合完成的定义？他们怎么能希望在入住之前做到这一点？

一个错误，就像 PBI 一样，当开发团队决定作为一个小组完成并且他们已经达到询问质量标准时，灰色设置为完成。

在 Scrum 模板中，错误是向 DoD 确认的产品级项目。但是，您可以在 sprint 计划会议上将该错误分解为多个任务，并且可以解决它们。错误的工作流程是：

1) 测试人员因测试失败而创建的错误。

2) 开发团队在 sprint 中接受了错误。

3) 将错误分解为至少用于编码和测试工作的任务。

4) Coder 修复了错误并解决了他们的任务。签入将此任务标记为完成。

5) 测试人员验证证明错误存在的测试用例现在通过了。他们将任务标记为完成。

6) 开发团队会见并根据 DoD 评估 Bug 的完成情况。如果完成，他们将其标记为完成。

【讨论】：

谢谢。我会将这个过程添加到我们的 bug 开发周期中（这也是我从之前的答案中意识到的，你的回答只是更加具体化了这一点，我最初误解了 alm 周期中 bug 工作项的意图）
好消息。尽管错误状态很容易在谷歌上搜索（如果这甚至是一个真实的词......）我一直假设敏捷和 SCRUM 模板的行为相同。

【解决方案3】：

错误流与任务不同。

提出了一个错误（测试人员/用户/开发人员）
修复了一个错误（开发者）
测试了一个错误（构建、集成到主构建、部署、测试人员测试）
一个错误已完成（由发起人签署）

是错误的一般流程，TFS ALM 假定修复和测试将由 2 个不同的角色完成。

如果您想更改它以反映任务工作流程，则必须更改模板

【讨论】：

【解决方案4】：

我们还使用 Microsoft.VSTS.Actions.Checkin 操作在开发和 QA 状态之间转换错误。开发者可以Associate 或Resolve，Resolve 触发状态改变attempt。但是，如果在转换中需要任何字段，例如根本原因，则转换将失败而不会出现任何错误消息。这是不幸的。如果错误弹出并说“请输入此字段”，那就太好了。如果在签入前填写了必填字段，则状态转换将按预期进行。

【讨论】：