如何在发布给所有人之前测试新的Azure DevOps扩展版本 [英] How to test new Azure DevOps extension version before publishing it for everyone

问题描述

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

I am using Azure DevOps (not TFS on-prem) and have my extension already published as public and many people using it. How can I push out a new version for just myself (or specific organizations) to test it, before making it public for everyone?

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

I know that I could roll all of the tasks in my Build/Release pipeline extension to v2, so if there are issues it wouldn't break in my users' systems right away until they flipped the task to use v2. However, I typically only want to increment the task version when there is a breaking change to it. Also, that still wouldn't address the issue of "I don't want ANY users to use the new version until I've tested it out first", as that could result in problems for my users and them giving bad ratings/reviews.

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

My initial thought was to flip the galleryFlags attribute in the vss-extension.json file from "Public" to "Preview" and push a new version, but I'm not certain if that will remove my extension from the marketplace, or if it will just publish the new version a "Preview" and leave the existing version available in the marketplace.

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

Before migrating to Azure DevOps, I was able to install new versions on the extension in our on-prem TFS instance from a local .vsix file without needing to publish them to the marketplace. It seems that running in the cloud does not offer this feature though, and Azure DevOps can only install extensions from the marketplace.

我提出了一个新的 GitHub问题以更新MS文档一些说明或建议.我还发现了类似的SO帖子，

I posed a new GitHub issue to have the MS documentation updated to give some instructions or recommendations on this. I also found this similar SO post, and this one, and the recommendation there was to create a 2nd publisher account and publish the same extension as private and share it with my organization. This would work, but seems very hacky to have to setup 2 separate publishing accounts and muck with the extension IDs before publishing each time for testing new versions of extensions.

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

I've created this new SO post (instead of following up on those existing ones) at the request of Microsoft so they can comment on it directly here.

推荐答案

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

When testing a new version of your extension, you need to use either use a different ExtensionID or a different PublisherID. And the test extension must be marked public: false.

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

There are multiple ways to make this process easy. I personally use the Azure DevOps Extension Tasks in different ways.

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

For my own private extension I have a build definition that builds either the public version or the private version. In the past I used to have 2 separate build definitions, but with YAML available I've started to consolidate this into a single definition. extensionTag is appended to the existing 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'))

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

I use the conditions to trigger either the public or the private publish function.

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

The end result looks like this in my publisher:

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

On the ALM Rangers account we use a build definition that builds a single vsix during build and then we use binary promotion to publish the vsix with different overrides. You don't need to use a different publisher in this case, but the Rangers do. The reason for this is that the Rangers used to publish to the MsDevDiv publisher and Microsoft didn't want to give every contributor access to that publisher and all of its extensions. So the separate publisher is used more to separate the concerns of developing the extension from providing support, answering questions and responding to reviews.

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

In order to test I publish the extension to a different Azure DevOps organisation. This is because you can't have two extensions installed to the same Azure DevOps organisation if both extensions contain the same Build Task Ids. In my case I use dev.azure.com/jessehouwing to build my extensions and use dev.azure.com/jessehouwing-dev to test the changes before making them publicly available.

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

For some extensions I publish a second private extension for early adopters:

• 扩展ID:jessehouwing.snyk-develop私下共享给jessehouwing-dev进行测试.
• 扩展名ID:jessehouwing.snyk-canary秘密地与几个选择的用户共享，供早期采用者使用.
• 扩展名ID:jessehouwing.snyk供公众使用.

• Extension ID: jessehouwing.snyk-develop privately shared to jessehouwing-dev for testing.
• Extension ID: jessehouwing.snyk-canary privately shared to a couple of select users for early adopters.
• Extension ID: jessehouwing.snyk for public use.

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

A couple of my customers have a special case where they work on an extension pack with multiple developers at the same time. To not have to provide each developer with a separate Azure DevOps organisation and build agents, they publish the test and public extension to a single account. In this case:

• 扩展名ID:publisher.extension专用于标准用法.
• 扩展ID:publisher.extension-branch，私有，内部开发和canary版本的预览.这些活动可以同时存在多个.

• Extension ID: publisher.extension private for standard usage.
• Extension ID: publisher.extension-branch, private, preview for internal development and canary releases. There can be multiple of these active at the same time.

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

To allow this each build task must have a unique Task ID for the Build tasks in in the extension. The Azure DevOps Extension Tasks have a special feature to generate unique IDs based on the publisher, extension-id, taskname. This feature is detailed in these release notes.

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

I recently presented at the MVP summit on these usage patterns. The presentation is shared here.

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

If you want to roll your own scripts then you can follow the following pattern:

• vss-extension.json-将扩展名的所有公共属性存储在此文件中.不要指定extensionid或galleryflags或public.
• vss-extension-test.json-存储测试版本唯一的值.其中包括:extensionid，galleryflags: preview，public: false.
• vss-extension-release.json-存储发行版独有的值.其中包括:extensionid，galleryflags: public，public: true.

• vss-extension.json - store all common properties of the extension in this file. Don't specify extensionid nor galleryflags nor public.
• vss-extension-test.json - store the values unique to the test version. These include: extensionid, galleryflags: preview, public: false.
• vss-extension-release.json - store values unique to release version. These include: 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.

• vss-extension.json - store all the details for the public extension
• vss-extension-override-test.json - store a json-patch file with the values you want to override. Again: 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自动增加构建任务的版本.

If you're rolling your own scripts, then you can use vsts-bump to auto-increase the version of your build tasks.

这篇关于如何在发布给所有人之前测试新的Azure DevOps扩展版本的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！