VSTS - Publish extension to private collection for testing [duplicate]

Question

I created some VSTS extension for internal use. I also created a CI/CD pipeline for these using the "CI/CD Tools for VSTS Extensions" by MS DevLabs. My approach has been to first push the extensions to a private testing VSTS collection and then once I have verified them I share them with my "prod" collections. I noticed yesterday though that my changes were immediately visible in my prod collections so I need to correct that.

Release Pipeline is as follows:

Test environment does a Publish Extension, Share Extension, and Install Extension.

• Publish: I have "Extension visibility" set to Private and "Share with" is set to my test collection.
• Share: "Share with" is set to my test collection.
• Install: "Install in" is set to my test collection

Prod environment does a Share and Install. Those push out to my prod collections. I have a Pre-deployment authorization set up so I can release to the prod environment after verifying Test. I haven't approved any changes yet so I do not expect my changes in the prod collection.

Why are my extension publishes immediately visible in my prod collections after only executing against the test environment? Is it because once I publish any collection that has installed my extension has visibility to new functionality? Do I need to set the visibility to private preview in my publish step?

If so does that mean I need to add a publish in my "prod" environment to change my extension from private preview to private? I have concerns I'll need to move the versioning step out of the build and into the release in that case. I'm assuming I can't publish the extension again without changing the version. Is that Share step necessary in test environment since share is part of the publish?

Quoit

Answer 1

We do versioning only once in the build. Each build increases the version number. These versions are then deployed. This could mean that your Public extension skips some versions since those are only deployed to the test environments. The build produces a VSIX.

We use two publisher accounts in the marketplace: alm-rangers and msdevlabs. The ALM Rangers one is used for all our private testing. msdevlabs is the public account that you find in the marketplace.

Each of our release environments has only one single task: Publish Extension. For our canary environment, we publish the extension as private. For msdevlabs as public.

Here are some screenshots:

I'm the ALM Ranger who worked on the Extension pipeline guidance so please let me know how to improve it!

Depredate

Thank you. I'll give this a shot. I bet having a second publisher account is the missing piece for me. – Quoit

Having a 2nd publisher account seems like a very hacky method to testing new versions of extensions before making them publicly available, especially when publish accounts need to be verified with personal information and the process can take many days. Perhaps things have changed since this post? I just created a GitHub issue to have the documentation updated to give some guidance around this problem. Perhaps you could weigh in. #47834699 – Zena

@Zena You don't need to supply the personal information for a private account. As long as you don't want to publish a public extension, no verification is needed. If you still don't like splitting your publishers, you could also add a tag to your extension and publish them to the same publisher while making sure your beta extensions are marked as private. – Depredate

Thanks for the info @WouterdeKort :) Also, I realize I posted the wrong link in my previous comment. I meant to post this one, which is a similar question to this one, and got a very good detailed answer there as well. #56029813 – Zena