在Jira中，您可以为项目创建发布。作为发行版的一部分，您可以指定发行版中包含哪些问题以及添加发行说明。
当您具有自动构建脚本时，这些功能非常有用，因为JIRA的API可以作为CD管道的一部分由脚本查询。
因此，您可以执行（但不限于）以下操作：
问题：是否有VSTS等效项？
答案 0 :(得分：1)
我认为当前没有任何可直接与Azure Devops中内置的Jira“发行版”相提并论的东西，它可以让您将板上完成的工作项打包为“发布”工作项。
您可以通过创建包含新的“发布”工作项类型的custom process for your project来实现“穷人”版本。然后，每个“发布工作项”都可以手动链接到要包含在该发行版中的工作项，并且可以包含“版本”编号或要与该发行版一起存储的任何其他元数据的自定义字段。然后可以从CD管道中查询此内容，以您的一个示例为例，该CD管道可以让您对发布的链接工作项进行类似的迭代，并确保它们处于“完成”状态。
编辑：作为集成技术的示例，REST API for Azure DevOps支持一个简单的REST GET请求，以查询项目中的所有工作项以获取自定义工作项类型：
GET https://dev.azure.com/{organization}/{project}/_apis/wit/reporting/workitemrevisions?types={YourCustomWorkItemType}&includeLatestOnly=true&api-version=4.1
API还将返回与此WIT关联的所有自定义字段，并将其列在WIT响应的“字段”对象内的键“ Custom。{YourFieldName}”下。
如果您的团队正在使用sprint，我想到的另一种可能的方法是将每个“ sprint”变成一个命名版本，一旦完成sprint，它将成为您的“发行版”。然后，未作为该sprint /版本/发行版的一部分实施的工作项将移至下一个sprint或关闭。我不确定这种方法对于复杂的项目是否可持续。
Azure Devops Features Timeline上列出了一些令人感兴趣的功能，这些功能可能会在不久的将来改善此工作流程（例如，计划于2018年第四季度实施的“发布可追溯性–工作项集成”），但很难找出任何实施细节。