2

我来自使用 Rally 和 Pivotal Tracker。在这两种方法中，我都可以将工作项分配给作为计划工具的版本，并记录已部署的工作项的历史记录。

即使有来自 Microsoft 的所有关于 Azure DevOps 的高度具体的指导，如何针对未来的版本组织工作仍然是沉默的。我什至看不到将工作项与发布相关联的地方。我在所有文档中是否缺少某些东西，或者是否有一些变通方法比仅使用标签来主动计划发布更强大？还是微软希望我使用一些单独的产品管理工具来管理针对版本的工作项？

4

1 回答 1

2

有多种技术可以实现这一点，而不是“一种方式”：

  1. 使用父迭代路径对您计划针对某个版本的迭代进行分组。当您在开始下一个版本之前完全完成一个版本时，这种方法效果最好。否则，它通常会因多次活动迭代而变得一团糟。

    Backlog Iteration
+ Release 1.0
  + Sprint 1
  + Sprint 2
  + Sprint 3
+ Release 2.0
  + etc

-

  1. 使用标签发布。在该版本中包含的所有工作项上添加标签 [Release 1.0]，这是最灵活的选项之一。

  2. 使用 Azure Pipelines 跟踪哪些工作项与哪些 Git 提交相关联，因此包含在哪些构建工件中。跨环境跟踪构建工件，通过查看中间构建来了解哪些工作项部署到环境中。

  3. 将自定义工作项字段添加到要跟踪的工作项类型。您可以更改正在使用的工作项流程，并且可以向工作项添加一个字段，您可以在其中指定版本名称/编号。有可用的自定义控件可以将版本号限定为特定列表，或者可以从任何 REST API 获取允许的值。

如您所见，Azure DevOps 在使用模式上更加灵活，但这也意味着有时您需要“找出最适合您的团队的方式”。

您可能感兴趣的另一个扩展是Bravo Notes 扩展。或者可以根据您的工作项数据、提交和/或管道工件生成发行说明的其他扩展之一。

于 2019-02-20T15:47:06.467 回答