如何在发布给所有人之前测试新的Azure DevOps扩展版本

我正在使用Azure DevOps（不是TFS本地版本），并且我的扩展程序已经公开发布，许多人正在使用它。在向所有人公开之前，我该如何为自己（或特定组织）推出新版本进行测试？

我知道我可以将Build / Release管道扩展中的所有任务都滚动到v2，因此，如果出现问题，直到用户翻转任务以使用v2时，它都不会立即在用户的系统中中断。但是，我通常只想在任务版本发生重大更改时增加任务版本。另外，这仍然无法解决“我不希望任何用户使用新版本，除非先对新版本进行测试”的问题，因为这可能会给我的用户带来麻烦，并且他们给出的评分/评论不佳。

我最初的想法是galleryFlags将vss-extension.json文件中的属性从“公开” 翻转为“预览”并推送新版本，但是我不确定这是否会将我的扩展名从市场中删除，或者是否只是发布新版本“预览”，并在市场上保留现有版本。

迁移到Azure DevOps之前，我能够从本地.vsix文件在本地TFS实例中的扩展名上安装新版本，而无需将它们发布到市场上。似乎在云中运行不提供此功能，并且Azure DevOps只能从市场上安装扩展。

我提出了一个新的GitHub问题，以更新MS文档，以对此提供一些说明或建议。我还发现了与此类似的SO帖子，以及该帖子，并建议创建第二个发布者帐户并发布与private相同的扩展名，并与我的组织共享。这是可行的，但似乎很棘手，必须在每次发布以测试新版本的扩展之前设置2个单独的发布帐户并添加扩展ID。

我应Microsoft的要求创建了这个新的SO帖子（而不是跟进那些现有的帖子），以便他们可以在此处直接发表评论。

测试扩展的新版本时，您需要使用其他ExtensionID或其他PublisherID。并且必须标记测试扩展名public: false。

有多种方法可以简化此过程。我个人以不同的方式使用Azure DevOps扩展任务。

对于我自己的私有扩展，我有一个构建定义，可以构建公共版本或私有版本。过去，我曾经有2个独立的构建定义，但是随着YAML的推出，我已经开始将其合并为一个定义。extensionTag附加到现有extensionId。

steps:
- task: ms-devlabs.vsts-developer-tools-build-tasks.package-extension-build-task.PackageVSTSExtension@1
  displayName: 'Package Extension: $(Build.SourcesDirectory)'
  inputs:
    rootFolder: '$(Build.SourcesDirectory)'
    outputPath: '$(Build.BinariesDirectory)\vsix\jessehouwing.azure-pipelines-snyk-task.vsix'
    outputVariable: CreateExtension.OutputPath
    publisherId: jessehouwing
    extensionId: 'vsts-snyk'
    extensionVersion: '$(Build.BuildNumber)'
    updateTasksVersion: true
    updateTasksVersionType: patch
    extensionVisibility: public

- task: ms-devlabs.vsts-developer-tools-build-tasks.publish-extension-build-task.PublishExtension@1
  displayName: 'Publish Extension Private'
  inputs:
    connectedServiceName: 'Jesse Houwing'
    fileType: vsix
    vsixFile: '$(CreateExtension.OutputPath)'
    extensionTag: '-develop'
    extensionVisibility: private
  condition: and(succeeded(), ne(variables['Build.SourceBranch'], 'refs/heads/master'))

- task: ms-devlabs.vsts-developer-tools-build-tasks.publish-extension-build-task.PublishExtension@1
  displayName: 'Publish Extension Public'
  inputs:
    connectedServiceName: 'Jesse Houwing'
    fileType: vsix
    vsixFile: '$(CreateExtension.OutputPath)'
    extensionVisibility: public
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master'))

我使用条件来触发公共或私有发布功能。

最终结果在我的发布商中如下所示：

在ALM Rangers帐户上，我们使用一个构建定义，该定义在构建期间构建单个vsix，然后使用二进制升级以不同的替代发布vsix。在这种情况下，您无需使用其他发布者，但游骑兵需要。这样做的原因是，Rangers曾经发布给MsDevDiv发布者，而Microsoft不想让每个贡献者都可以访问该发布者及其所有扩展。因此，更多地使用单独的发布者来将开发扩展的关注点与提供支持，回答问题以及回复评论分开。

为了进行测试，我将扩展发布到其他Azure DevOps组织。这是因为如果两个扩展都包含相同的生成任务ID，则无法将两个扩展安装到同一个Azure DevOps组织。就我而言，我用于dev.azure.com/jessehouwing构建扩展并用于dev.azure.com/jessehouwing-dev在将更改公开发布之前测试更改。

对于某些扩展，我为早期采用者发布了第二个私有扩展：

扩展ID：jessehouwing.snyk-develop私下共享以jessehouwing-dev进行测试。

扩展ID：jessehouwing.snyk-canary与早期选择者私下共享给几个选定的用户。

扩展ID：jessehouwing.snyk供公众使用。

我的几个客户有一个特殊情况，他们与多个开发人员同时使用扩展包。为了不必为每个开发人员提供单独的Azure DevOps组织和构建代理，他们可以将测试和公共扩展发布到单个帐户。在这种情况下：

扩展ID：publisher.extension专用于标准用法。

扩展ID publisher.extension-branch：，私有，用于内部开发和Canary版本的预览。这些活动可以同时存在多个。

为此，每个扩展任务中的构建任务必须具有唯一的任务ID。Azure的DevOps的支线任务有一个特殊的功能，基于独特的ID publisher，extension-id，taskname。这些发行说明中详细介绍了此功能。

我最近在MVP峰会上介绍了这些使用模式。演示在这里共享。

如果要滚动自己的脚本，则可以遵循以下模式：

vss-extension.json-将扩展名的所有常用属性存储在此文件中。请勿指定extensionid或galleryflags或public。

vss-extension-test.json-存储测试版本独有的值。这些措施包括：extensionid，galleryflags: preview，public: false。

vss-extension-release.json-存储发行版独有的值。这些措施包括：extensionid，galleryflags: public，public: true。

然后调用：

// deploy test
tfx extension publish --manifest-globs vss-extension.json vss-extension-test.json
// deploy release
tfx extension publish --manifest-globs vss-extension.json vss-extension-release.json

发布合并的清单。

或使用替代清单：

vss-extension.json -存储公共扩展的所有详细信息

vss-extension-override-test.json-使用您要覆盖的值存储一个json-patch文件。还是那句话：extensionid，galleryflags: preview，public。

然后使用

// deploy test
tfx extension publish --manifest-globs vss-extension.json --override-file vss-extension-override-test.json
// deploy release: 
tfx extension publish --manifest-globs vss-extension.json

如果您要滚动自己的脚本，则可以使用vsts-bump来自动增加构建任务的版本。