在测试新版本的扩展程序时，您需要使用不同的 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 需要。原因是 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，私有，内部开发和金丝雀版本的预览。可以同时有多个处于活动状态。
为了实现这一点，每个构建任务都必须有一个唯一的任务 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。