We publish a UWP Windows app to the Windows Store and generate a sideload bundle for manual installation.
We have three different environments: development, staging, and production. Each can be deployed to the Windows Store or installed manually on the client’s machine. Thus, we have to build the application 6 times because we have 3 different environments and 2 target deployments – 1 build per environment and 1 build per target deployment (Windows and Sideloading). We must build the app twice per environment because we need to sign the application with different certificates depending on whether we deploy it to the Windows store or generate a bundle for sideloading. When deploying to the Windows store, we use a self-signed certificate with Publisher set to the Application ID in the Windows partner center (a requirement from the Windows store). When generating a sideloaded application bundle, we sign the application with a trusted certificate we’ve purchased from a certificate authority, allowing seamless and secure installation on the customers’ devices.
The application targets x86, x64, and ARM architectures. We use native toolchain build. The application build takes about 43 minutes on a very beefy virtual machine. And considering we have to build 6 times, do the math; it’s about 4.5 hours of build time.
We’ve utilized a single-build strategy for the iOS version of the application. The app bundle for iOS is built only once. Each environment has it’s own Bundle ID. Once the build is done and we want to deploy the app to a specific environment, we use fastlane to change the bundle ID of the app to the environment-specific value and resign the bundle with the environment-specific certificate. Resigning a bundle takes several seconds, compared to 15 minutes of iOS build time. Thus, not only we have a very fast deployment pipeline, but we are also sure that we deploy the same binaries when we progress through the release train and the environments. Then, in the runtime, we can read the application bundle ID and choose the environment based on that, and connect to the correct servers.
Considering the UWP build is at least 3 times slower than the iOS build, we must find a similar single-build strategy for the UWP app. For that, we need to solve 2 problems.
- Be able to change the
Package.appxmanifest
, (or perhaps another file) post-build and add some kind of value that will indicate the environment so that we can read that value runtime and identify the environment of the app. The key is to do this after the bundle is generated, and the indicator should be accessible at runtime. - Be able to re-sign the bundle post-build with a different certificate. The new signature should also override all signatures on all files inside the bundle directory, such as binaries, dependencies and the installation scripts (yes, those files are signed with the certificate that you specify build-time.
Is this doable? Are there any ready-made tools to achieve this?