【问题标题】:No way to group work items into releases in TFS 2015?无法在 TFS 2015 中将工作项分组到版本中?
【发布时间】:2016-01-16 20:09:37
【问题描述】:

我的团队刚刚开始在本地使用 TFS 2015 Update 1 来管理他们的开发过程。我已经设置了服务器并为工作项定义了一些自定义状态和转换,以便更好地映射到我们的流程。首先,我们将仅利用看板,而不是尝试使用迭代,原因有多种,我不会在这里讨论。

我目前的问题是使用 TFS 来计划发布。具体来说,我看不到任何将功能和用户故事分组到特定版本中的方法。我所有的谷歌搜索都找到了许多涉及 Microsoft 发布管理的文章,所以我安装并配置了它,但这对于我的团队现在正在尝试做的事情来说绝对是矫枉过正。目前我并没有尝试将部署自动化到不同的环境,我只需要一种方法将工作项组合成一个封装 TFS 中发布概念的东西。有没有办法做到这一点?我现在能想到的最好的办法是进一步修改工作项模板,以提供一个带有选择列表的简单“发布”字段,或者定义另一种类型的工作项,我可以将其他工作项分组到其中。从我的角度来看,这似乎是 MS 的明显疏忽,所以我希望我只是遗漏了一些东西。

【问题讨论】:

  • 我的团队完全按照您描述的原因使用了自定义“发布”工作项模板。它工作得很好。我的首要建议是不要使用子父关系将项目链接到发布,如果发布中的项目已经具有逻辑父级(例如功能切片),则可能会导致问题。
  • 好吧,我很失望发布计划显然没有在 TFS 中考虑,但感谢您的意见。这是我现在要提出的方向。

标签: tfs release-management tfs-2015


【解决方案1】:

可以通过多种方式将工作分组到发布中,只要记住“发布计划”的概念在 TFS 中并不明确存在。发布管理涵盖“发布到生产”,但不包括任何规划。

计划发布的方式:

  • 一种方法是创建一个版本迭代,当您没有同时处理多个版本并真正完成一个版本然后再处理下一个版本时,这很有效。 Release 迭代曾经是默认的,但已从产品中删除,以支持团队交付 sprint 和团队进行持续交付。

    Project Root
    + Release 1.2
      + Sprint 1
      + Sprint 2
    
  • 另一种选择是使用标签。您可以使用标记来标记工作项,以表明它针对特定的 sprint。

  • 使用标记工作项,在待办事项列表中放置一个明显突出的工作项### END OF RELEASE 1 ### 其下方的任何工作项不是该版本的一部分。这种技术适合一种更敏捷的工作方式,并且更清楚地表明发布的内容是浮动的。

  • 创建一个自定义发布工作项,将您的其他工作项链接到此工作项,以针对该发布进行定位。

  • 您可以选择在*自定义工作项字段**上创建选项列表。

【讨论】:

    【解决方案2】:

    或者,您也可以使用与迭代路径大致相同的方式使用区域路径。通过使用区域路径,您可以避免将 sprint 绑定到某个特定版本。

    这不是最好的解决方案,但在某些情况下可能是解决方案。

    【讨论】:

      【解决方案3】:

      仅根据您关于计划发布的问题回答,然后:

      1. 创建一个名为“部署”的自定义工作项模板。
      2. 开始计划发布时,创建一个新的“部署”,比如说,名为“MyProduct v1.1”。
      3. 在您的计划会议中,适当地创建功能和用户故事,并创建与“MyProduct v1.1”部署的关系,方法是打开用户故事并添加一个链接(使用部署工作项编号)作为“相关” .
      4. 要监控部署,请创建针对新“部署”工作项模板的自定义工作项查询。您可以将其配置为显示在仪表板上。
      5. 根据“部署”及其关系执行您喜欢的任何发布程序。

      在创建“部署”时应遵循命名约定以保持一致性。

      附言我建议在这种情况下使用扩展“工作项可视化”。它会很好地绘制出与“部署”相关的工作项。

      如果您想使用 TFS 来实际构建和创建 Release,那么 Release Manager 值得考虑。

      TFS 2015 Update 2.1 现在包括一个内置版本的 Release Manager。与 Release Manager 独立安装相比,它更加用户友好且易于配置。

      要将工作项分组为“发布”,您可以执行以下操作:

      1. 为您正在使用的存储库创建构建定义 - 请参阅 Build Def creation docs
      2. 创建发布定义 - 请参阅 Release Def creation docs

      创建这些定义后,工作流程将是:

      1. 开发人员针对工作项工作
      2. 根据 WI 编号(或任务)进行提交
      3. 创建版本时,请在您创建的定义上开始构建。在此过程中,WI 将与内部版本号相关联。
      4. 构建成功后,根据您创建的定义启动新版本。
      5. 您有一组与发布相关的工作项,请参见屏幕截图:

      注意:您可以启用 CI 构建和发布,尽管以上是基于手动触发器。

      您也可以直接调用 Release API 来定位与 Releases 关联的 WI,但您需要先获取该版本的实际 Id。

      但是,您目前只能在了解版本的情况下查看这些关系。在现实世界的场景中,查看工作项以了解它何时发布更为现实。为此,目前没有内置功能,但我自己回答的问题将指导您 - see here.

      【讨论】:

      • 希望这对某人有所帮助,但它并没有真正回答我最初的问题,即计划发布,而不是构建它们。
      • 修改答案以更适合您的问题
      【解决方案4】:

      除了 jessehouwing 解释的方法之外,还有一些第三方工具可以与 TFS/VSTS 集成并提供高级规划功能。有关概述,请参阅VSTS Marketplace

      【讨论】:

        猜你喜欢
        • 2016-05-07
        • 1970-01-01
        • 1970-01-01
        • 2019-07-14
        • 1970-01-01
        • 2013-04-10
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多