Deployment enhancements

[clairernovotny]

Hi,

I was looking to see if you'd be interested in ways to improve the deployment experience? I have a lot of experience in building/deploying appx's.

A few thoughts:

• You can use AppInstaller and publish built appx/appxbundles to a storage location. That will enable auto-updating without needing to go through the store. Even with a store version, you can have a separate "nightly"/"CI" channel.
• Tools like NerdBank.GitVersioning enable updating the version per-build. This enables continuous deployment to different channels since package version numbers are set.
• A code signing cert will enable use without any manual install or certificate prompts. They are available for about $80/year from some vendors.
• Code signing can be automated in a service, so it's easy to ensure the appxmanifest matches the cert
• The local cert (pfx) that you have for the store is not secret; it's a self-signed cert where the subject happens to match the store id. It is safe to check-in. The store signs the package with a different cert where it has the private key. It would be easier to check that in.
• A tool like Bugsnag, which has an OSS plan, can help catch exceptions you don't see locally.
• Releases, to blob storage/the store, can be all automated using Azure Pipelines release management (for free for OSS projects). It has 10 concurrent builds for free for OSS projects.

I'm happy to discuss any/all of this if you're interested. Here's one example of this all put together:
https://github.com/NuGetPackageExplorer/NuGetPackageExplorer

[felixse]

Thank you very much for offering your help. I would really love to go in that direction. I think the top priorities are auto updating channels for stable and nightly builds, but I guess this involves pretty much all of what you described above. So how do we start on this? 😃

[clairernovotny]

@felixse One thing that will greatly reduce friction in most of this is the code signing cert. Is that something you're able to obtain? Here's one of the cheaper ones I've found: https://codesigncert.com/comodocodesigning

[felixse]

I just ordered one, but might take some days until everything is validated.

[clairernovotny]

Cool...so where you want to go next is up to you -- there are several options.

If you want to code sign manually, you can do that using the cert. The subject on the manifest needs to match whatever the cert says. Otherwise, you can install an instance of the code signing service into your azure account (https://github.com/onovotny/SignService), instructions are in there. That can let you automate it safely. The cert can be uploaded to a key vault instance.

The next steps are around deployment/automation. For versioning, I keep a sentinel value (3.25 in my case) in my checked-in manifest file, then update them in the build script. The other thing I do is manually update the appinstaller file, but you can also have the build system generate it. AppInstaller is the key to doing automatic updates since you can specify the update frequency.

What would be the most helpful here; do you want to take a look at the build scripts & structure from NuGet Package Explorer, adapt it and then I can answer questions? I'm traveling the next several days so likely cannot do a direct PR before at least next week.

[felixse]

Thanks for the summary. I think I will set up a basic Azure Pipelines build definition and have a closer look at Nuget Package Explorer (great tool btw) in the meantime. Sign Service looks great, the automated route will definitively be what I aim for. Once the cert arrives I will give this a try, but maybe expect some questions 😄

[clairernovotny]

Another option for code signing would be to use AzureSignTool directly. That doesn't require a service to be deployed/running, which may be overkill for your needs. That tool is scriptable as a .NET Core tool and for that you'd just need a key vault and then to grant a ServicePrinicpal/application to it and hold onto the ClientId/client secret.

That approach is simpler to deploy since there's no service code but would be geared around only signing the appx/appxbundle's (which have to be done "inside-out," recursively). The appxmanifest would also need to match the subject in the cert, whereas the service sets that automatically, so the dev cert/subject doesn't need to match.

I'll answer any question I can :)