При тестировании новой версии вашего расширения вам нужно использовать либо другой ExtensionID, либо другой PublisherID.И тестовое расширение должно быть помечено public: false.
. Есть несколько способов сделать этот процесс простым.Я лично использую Задачи расширения Azure DevOps по-разному.
Для моего собственного частного расширения у меня есть определение сборки, которое создает либо публичную, либо приватную версию.Раньше у меня было 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.с разными переопределениями.Вам не нужно использовать другого издателя в этом случае, но рейнджеры это делают.Причина этого заключается в том, что Рейнджерс раньше публиковал для издателя MsDevDiv, и Microsoft не хотела предоставлять каждому участнику доступ к этому издателю и всем его расширениям.Таким образом, отдельный издатель используется больше, чтобы отделить заботу о разработке расширения от предоставления поддержки, ответов на вопросы и ответов на отзывы.
Чтобы протестировать, я публикую расширение в другой организации DevOps Azure.Это связано с тем, что нельзя установить два расширения в одну и ту же организацию DevOps Azure, если оба расширения содержат одинаковые идентификаторы задач сборки.В моем случае я использую dev.azure.com/jessehouwing для сборки своих расширений и dev.azure.com/jessehouwing-dev для тестирования изменений перед тем, как сделать их общедоступными.
Для некоторых расширений я публикую второе частное расширение для ранних пользователей:
- Идентификатор расширения:
jessehouwing.snyk-develop для общего доступа jessehouwing-dev для тестирования. - Идентификатор расширения:
jessehouwing.snyk-canary для общего доступа нескольким избранным пользователям для ранних пользователей. - Идентификатор расширения:
jessehouwing.snyk для публичного использования.
У пары моих клиентов есть особый случай, когда они работают над пакетом расширений одновременно с несколькими разработчиками.Чтобы не предоставлять каждому разработчику отдельную организацию Azure DevOps и агенты сборки, они публикуют тестовое и общедоступное расширение в одной учетной записи.В этом случае:
- Идентификатор расширения:
publisher.extension частный для стандартного использования. - Идентификатор расширения:
publisher.extension-branch, частный, предварительный просмотр для внутренней разработки и канареечных выпусков.Одновременно их может быть несколько.
Для этого у каждой задачи сборки должен быть уникальный идентификатор задачи для задач сборки в расширении.Задачи расширения DevOps Azure имеют специальную функцию для создания уникальных идентификаторов на основе publisher, extension-id, taskname.Эта функция подробно описана в этих заметках о выпуске .
Я недавно представил на саммите 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.
Затем вызовите:
// 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 для автоматического увеличения версии ваших задач сборки .