如何在为所有人发布之前测试新的 Azure DevOps 扩展版本
How to test new Azure DevOps extension version before publishing it for everyone
我正在使用 Azure DevOps（不是本地 TFS）并且我的扩展已经发布为 public 并且很多人都在使用它。在为所有人 public 之前，我如何才能为自己（或特定组织）推出一个新版本来测试它？
我知道我可以将 Build/Release 管道扩展中的所有任务滚动到 v2，因此如果出现问题，它不会立即破坏我用户的系统，直到他们将任务翻转到使用 v2。但是，我通常只想在有重大更改时增加任务版本。此外，这仍然无法解决 "I don't want ANY users to use the new version until I've tested it out first" 的问题，因为这可能会给我的用户带来问题，并且他们会给出错误的 ratings/reviews.
我最初的想法是将 vss-extension.json 文件中的 galleryFlags 属性从 "Public" 翻转为 "Preview" 并推送一个新版本，但我不确定如果这会将我的扩展程序从市场中删除，或者如果它只是发布新版本 "Preview" 并在市场上保留现有版本。
在迁移到 Azure DevOps 之前，我能够从本地 .vsix 文件在本地 TFS 实例的扩展上安装新版本，而无需将它们发布到市场。 运行 in the cloud 似乎不提供此功能，而 Azure DevOps 只能从市场安装扩展。
我提出了一个新的 GitHub issue to have the MS documentation updated to give some instructions or recommendations on this. I also found , ，那里的建议是创建第二个发布者帐户并将相同的扩展发布为私有并与我的组织共享。这会工作，但似乎非常 hacky 必须设置 2 个单独的发布帐户并在每次发布之前处理扩展 ID 以测试新版本的扩展。
我应 Microsoft 的要求创建了这个新的 SO post（而不是跟进那些现有的），以便他们可以直接在此处发表评论。
测试扩展的新版本时，您需要使用不同的 ExtensionID 或不同的 PublisherID。并且测试扩展必须标记为public: false.
有多种方法可以简化此过程。我个人以不同的方式使用 Azure DevOps Extension Tasks。
对于我自己的私有扩展，我有一个构建定义，它构建 public 版本或私有版本。过去，我曾经有 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'))
我使用条件来触发 public 或私人发布功能。
最终结果在我的发布者中看起来像这样：
在 ALM Rangers 帐户上，我们使用构建定义在构建期间构建单个 vsix，然后我们使用二进制提升来发布具有不同覆盖的 vsix。在这种情况下，您不需要使用不同的发布者，但 Rangers 需要。这样做的原因是 Rangers 过去常常发布到 MsDevDiv 发布者，而 Microsoft 不想让每个贡献者都可以访问该发布者及其所有扩展。因此，单独的发布者更多地用于将开发扩展的关注点与提供支持、回答问题和回复评论分开。
为了测试，我将扩展发布到不同的 Azure DevOps 组织。这是因为如果两个扩展包含相同的生成任务 ID，则不能将两个扩展安装到同一个 Azure DevOps 组织。在我的例子中，我使用 dev.azure.com/jessehouwing 来构建我的扩展，并使用 dev.azure.com/jessehouwing-dev 来测试更改，然后再使它们 public 可用。
对于某些扩展，我为早期采用者发布了第二个私有扩展：
- 扩展 ID：
jessehouwing.snyk-develop 私下共享给 jessehouwing-dev 进行测试。
- 扩展 ID：
jessehouwing.snyk-canary 私下共享给几个 select 早期采用者的用户。
- 分机 ID：
jessehouwing.snyk 供 public 使用。
我的几个客户有一个特殊情况，他们同时与多个开发人员一起开发扩展包。为了不必为每个开发人员提供单独的 Azure DevOps 组织和构建代理，他们将测试和 public 扩展发布到单个帐户。在这种情况下：
- 扩展 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 - 存储 public 扩展 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。
我正在使用 Azure DevOps（不是本地 TFS）并且我的扩展已经发布为 public 并且很多人都在使用它。在为所有人 public 之前，我如何才能为自己（或特定组织）推出一个新版本来测试它？
我知道我可以将 Build/Release 管道扩展中的所有任务滚动到 v2，因此如果出现问题，它不会立即破坏我用户的系统，直到他们将任务翻转到使用 v2。但是，我通常只想在有重大更改时增加任务版本。此外，这仍然无法解决 "I don't want ANY users to use the new version until I've tested it out first" 的问题，因为这可能会给我的用户带来问题，并且他们会给出错误的 ratings/reviews.
我最初的想法是将 vss-extension.json 文件中的 galleryFlags 属性从 "Public" 翻转为 "Preview" 并推送一个新版本，但我不确定如果这会将我的扩展程序从市场中删除，或者如果它只是发布新版本 "Preview" 并在市场上保留现有版本。
在迁移到 Azure DevOps 之前，我能够从本地 .vsix 文件在本地 TFS 实例的扩展上安装新版本，而无需将它们发布到市场。 运行 in the cloud 似乎不提供此功能，而 Azure DevOps 只能从市场安装扩展。
我提出了一个新的 GitHub issue to have the MS documentation updated to give some instructions or recommendations on this. I also found
我应 Microsoft 的要求创建了这个新的 SO post（而不是跟进那些现有的），以便他们可以直接在此处发表评论。
测试扩展的新版本时，您需要使用不同的 ExtensionID 或不同的 PublisherID。并且测试扩展必须标记为public: false.
有多种方法可以简化此过程。我个人以不同的方式使用 Azure DevOps Extension Tasks。
对于我自己的私有扩展，我有一个构建定义，它构建 public 版本或私有版本。过去，我曾经有 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'))
我使用条件来触发 public 或私人发布功能。
最终结果在我的发布者中看起来像这样：
在 ALM Rangers 帐户上，我们使用构建定义在构建期间构建单个 vsix，然后我们使用二进制提升来发布具有不同覆盖的 vsix。在这种情况下，您不需要使用不同的发布者，但 Rangers 需要。这样做的原因是 Rangers 过去常常发布到 MsDevDiv 发布者，而 Microsoft 不想让每个贡献者都可以访问该发布者及其所有扩展。因此，单独的发布者更多地用于将开发扩展的关注点与提供支持、回答问题和回复评论分开。
为了测试，我将扩展发布到不同的 Azure DevOps 组织。这是因为如果两个扩展包含相同的生成任务 ID，则不能将两个扩展安装到同一个 Azure DevOps 组织。在我的例子中，我使用 dev.azure.com/jessehouwing 来构建我的扩展，并使用 dev.azure.com/jessehouwing-dev 来测试更改，然后再使它们 public 可用。
对于某些扩展，我为早期采用者发布了第二个私有扩展：
- 扩展 ID：
jessehouwing.snyk-develop私下共享给jessehouwing-dev进行测试。 - 扩展 ID：
jessehouwing.snyk-canary私下共享给几个 select 早期采用者的用户。 - 分机 ID：
jessehouwing.snyk供 public 使用。
我的几个客户有一个特殊情况，他们同时与多个开发人员一起开发扩展包。为了不必为每个开发人员提供单独的 Azure DevOps 组织和构建代理，他们将测试和 public 扩展发布到单个帐户。在这种情况下：
- 扩展 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- 存储 public 扩展 的所有详细信息
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。