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

问题描述

我使用的是 Azure DevOps(不是本地 TFS)并且我的扩展已经公开发布并且很多人都在使用它.在向所有人公开之前，我如何才能推出仅供我自己(或特定组织)测试的新版本?

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

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

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

我提出了一个新的

在 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.此功能在这些发行说明中有详细说明.

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

如果你想推出自己的脚本，那么你可以遵循以下模式:

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

然后调用:

//部署测试tfx 扩展发布 --manifest-globs vss-extension.json vss-extension-test.json//部署发布tfx 扩展发布 --manifest-globs vss-extension.json vss-extension-release.json

发布合并的清单.

或者使用覆盖清单:

• vss-extension.json - 存储公共扩展的所有详细信息
• vss-extension-override-test.json - 存储一个 json-patch 文件，其中包含要覆盖的值.再次:extensionid, galleryflags: preview, public.

然后使用

//部署测试tfx 扩展发布 --manifest-globs vss-extension.json --override-file vss-extension-override-test.json//部署发布:tfx 扩展发布 --manifest-globs vss-extension.json

如果您要滚动自己的脚本，那么您可以使用 vsts-bump 自动增加构建任务的版本.

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?

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.

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.

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.

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.

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.

解决方案

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.

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

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)vsixjessehouwing.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:

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.

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:

• 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.

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:

• 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.

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.

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 - 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.

Then invoke:

// 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

To publish the combined manifests.

Or use an override manifest:

• 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.

Then use

// 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

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屋！