如何在发布新的Azure DevOps扩展版本之前进行测试？

Question

如何在发布新的Azure DevOps扩展版本之前进行测试？

8

我正在使用Azure DevOps（而不是TFS on-prem），我的扩展已经作为公共扩展发布，有许多人在使用它。在将其公开发布给所有人之前，我该如何推出一个新版本供自己（或特定组织）测试？

我知道我可以将构建/发布管道扩展中的所有任务都升级到v2，这样如果出现问题，它就不会立即在用户的系统中崩溃，直到他们将任务切换到使用v2。然而，通常情况下，我只想在它存在重大变更时增加任务版本。此外，这仍然无法解决“在我测试之前，我不希望任何用户使用新版本”的问题，因为这可能会给我的用户带来问题，并导致他们评价和评论不佳。

我的最初想法是将vss-extension.json文件中的galleryFlags属性从“Public”翻转为“Preview”，然后推出一个新版本，但我不确定是否会将我的扩展从市场上移除，还是只会发布新版本作为“预览”，并保留现有版本在市场上可用。

在迁移到Azure DevOps之前，我能够从本地的.vsix文件中安装新版本的扩展程序到我们的本地TFS实例上，而无需将其发布到市场。然而，在云端运行似乎没有这个功能，Azure DevOps只能从市场安装扩展程序。

我提出了一个GitHub问题，要求更新MS文档以提供一些说明或建议。我还发现了这个相似的SO帖子和这个帖子，那里的建议是创建第二个发布者帐户并将相同的扩展程序作为私有扩展程序发布，并与我的组织共享。这样做是可行的，但每次测试扩展程序的新版本时都需要设置两个单独的发布帐户并混淆扩展ID，似乎很麻烦。

我创建了这个新的SO帖子（而不是跟进那些现有的帖子），根据微软的要求，他们可以直接在这里进行评论。

- deadlydog

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- jessehouwing · Accepted Answer

测试新版本扩展时，您需要使用不同的ExtensionID或PublisherID。测试扩展必须标记为public: false。

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

对于我自己的私有扩展，我有一个构建定义，可以构建公共版本或私有版本。过去，我曾经使用两个单独的构建定义，但随着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这样做。原因是Rangers曾经发布到MsDevDiv发布者，而Microsoft不想给每个贡献者访问该发布者及其所有扩展的权限。因此，分开的发布者更多地用于分离开发扩展和提供支持、回答问题和响应评论的关注点。

为了测试，我将扩展程序发布到另一个Azure DevOps组织。这是因为如果两个扩展都包含相同的Build Task Ids，则不能将两个扩展安装到同一个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，私人，预览用于内部开发和金丝雀版本。可以同时存在多个这样的扩展。

要允许此操作，每个构建任务必须在扩展中具有唯一的任务ID。 Azure DevOps扩展任务具有根据publisher、extension-id、taskname生成唯一ID的特殊功能。此功能在这些发布说明中详细介绍。

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

如果要编写自己的脚本，则可以按照以下模式操作：

vss-extension.json - 在此文件中存储扩展的所有
```
// 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 自动增加构建任务的版本号。