PROSAGA码农传奇-Jira-在VSTS中是否有相当于Jira-Releases？

<div class =“post-text”itemprop =“text”>
  
    我认为目前没有任何可与Azure Devops中内置的Jira'版本直接比较的内容，这可以让您将已完成的工作项打包到“发布”工作项中。
  
  
    你可以通过创建一个“实现”的“穷人”版本
    <a href =“https://docs.microsoft.com/en-us/azure/devops/organizations/settings/work/customize-process?view=vsts&tabs=new-nav#add-or-modify-work -item-types“rel =”nofollow noreferrer“>
      您的项目的自定义过程
    </A>
     其中包括一个新的“发布”工作项类型。然后，每个“发布工作项”可以手动链接到您要包含在该版本中的工作项，并且可以包含“版本”编号的自定义字段或您希望与该版本一起存储的任何其他元数据。然后可以从CD管道中查询，然后根据您的一个示例，允许您执行某些操作，例如迭代已发布的链接工作项并确保它们处于“完成”状态。
  
  
    的
      编辑：
    </强>
     作为集成技术的一个例子，
    <a href =“https://docs.microsoft.com/en-us/rest/api/azure/devops/wit/reporting%20work%20item%20revisions/read%20reporting%20revisions%20get?view=azure-devops -rest-4.1“rel =”nofollow noreferrer“>
      Azure DevOps的REST API
    </A>
     支持简单的REST GET请求，以查询项目中的所有工作项以获取自定义工作项类型：
  
   <pre>
 <code>
 GET https://dev.azure.com/{organization}/{project}/_apis/wit/reporting/workitemrevisions?types={YourCustomWorkItemType}&includeLatestOnly=true&api-version=4.1

</code>
 </pre>
  
    API还将返回与此WIT关联的任何自定义字段，并在WIT响应的“fields”对象中的“Custom。{YourFieldName}”下列出它们。
  
  
    如果你的团队正在使用sprint，那么我想到的另一个可能的方法就是让每个'sprint'成为一个命名版本，一旦sprint完成就会成为你的'release'。然后，将未作为sprint / version / release的一部分实现的工作项移动到下一个sprint中或关闭。我不确定这种方法对复杂项目是否可持续。
  
  
    有一些感兴趣的功能列在
    <a href="https://docs.microsoft.com/en-us/azure/devops/release-notes/" rel="nofollow noreferrer">
      Azure Devops功能时间轴
    </A>
     这可能会在不久的将来改善这种工作流程（例如，“发布可追溯性”工作项集成“，计划于2018年第四季度实施），尽管很难找到任何实施细节。
  
</DIV>