How do I publish a UWP package to the Windows Store via Azure Devops?

Question

I am using Desktop Bridge with a c# Winforms application to make a package to publish to the store.

If I make my package locally using Desktop Bridge then I can upload it to the windows store successfully.

I am also now able to build and create the package artifact using a pipeline and I can see it in the Artifacts explorer.

I am having trouble following the docs on how to get the package into the store.

It mentions

ps

$(Build.ArtifactStagingDirectory)\
AppxPackages\MyUWPApp__$(AppxVersion)_x86_x64_ARM_bundle.appxupload

Does ps mean powershell?

How do I get the YAML?

Or am I meant to build a release pipeline?

I tried looking at the release tasks but could not find anything that mentioned the Store.

Answer 1

This is a great article on how to build your package and deploy it to Hockey App (now App Center) but can be used to deploy to the store as well. I'm not sure exactly how you would convert it to YAML, but it shouldn't be too difficult.
https://mobilefirstcloudfirst.net/2016/02/continuous-deployment-of-windows-10-uwp-apps-to-hockeyapp-using-vsts/

Once you have the package built following the instructions in the article (It sound's like you already have), skip the Hockey App steps and instead publish to the store with this Azure DevOps extension task step: https://marketplace.visualstudio.com/items?itemName=MS-RDX-MRO.windows-store-publish

Instructions to use the extension are on the extensions web page. You'll have to have an Azure Active Directory account. If you don't have one, it's easy to set up and it's free!

To answer your questions

1. Does ps mean powershell? - I just browsed down through the article and I don't think so. Usually it's saying you need to give this value in a property in the build step.
2. YAML is pretty new, and there is not, as far as I know, an easy way to convert it to YAML.
3. You'll probably want to do this in two steps: 1) Build the package and upload the artifact. 2) Download and release the package. Step 1 should be done in a build, step 2 should be done in a release. I find splitting these steps into two very helpful when only the release fails. Then I don't have to rebuild the package to try again, I can just redeploy the release.