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

Question

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

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

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

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

我提出了一个新的GitHub issue to have the MS documentation updated，以对此提供一些说明或建议。我还发现了this similar SO post，and this one，建议创建第二个发布者帐户并发布与私有相同的扩展名，并与我的组织共享。这是可行的，但在每次发布以测试新版本的扩展之前必须设置2个单独的发布帐户并添加扩展ID似乎很不明智。

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

Answer 1

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

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

对于我自己的私有扩展，我有一个构建定义，可以构建公共版本或私有版本。过去，我曾经有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扩展任务具有一项特殊功能，可基于publisher，extension-id，taskname生成唯一的ID。这个feature is detailed in these release notes。

我最近在MVP峰会上介绍了这些使用模式。 The presentation is shared here。

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

• 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

如果要滚动自己的脚本，请then you can use vsts-bump to auto-increase the version of your build tasks。