Refactoring and adding unit tests to deployment

[guimafelipe]

This Pull Request introduces a refactoring on the DeploymentManager.cpp class implementation. The goal is to facilitate bug tracking and the implementation of more localized tests, making it easier to implement new changes, tracking possible regressions in inner behaviors and also on isolating the causes of existing failures.

New modules

For this change if focused on the Initialize method. More specifically, on the internal _Initialize method. _Initialize calls a internal method Deploy(..), which is a 3 lines method that calls InstallLicenses(...) and DeployPackages(...).

These two methods were the main target of the refactoring. Let's go into each of them in details next.

Install licenses

This method is responsible for installing the licenses for the packages (Main and Singleton (and DDLM)) before installing them.
I separated it and extracted to a new namespace as the functions WindowsAppRuntime::Deployment::Deployer::GetLicenseFiles and WindowsAppRuntime::Deployment::Deployer::InstallLicenses.

GetLicenseFiles

This function's responsibility is to just iterate in the filesystem and return an array with the license files to install. Can be independently tested from the actual installation of the licenses.

InstallLicences

This function receives the list of licenses to install and uses the LicenseInstaller to execute the installation. The license installer is a stubbed file in the repository and we don't have access to its implementation. For this, I added an interface ILicenseInstaller that this function accepts as parameter. The DeployementManager::InstallLicenses implements a simple proxy/wrapper class around the real object and passes to the function. This gives us full control for mocking the installer on our tests and also a layer of separation for this namespace to not have strong dependency on the installer.

Deploy Packages

This method is responsible for doing the actual deployment after the licenses were installed. I also divided this method in 2 functions with separated responsibilities: WindowsAppRuntime::Deployment::Deployer::GetDeploymentPackageArguments and WindowsAppRuntime::Deployment::Deployer::DeployPackages.

GetDeploymentPackageArguments

This function is responsible for building the vector with the package arguments that we will use later to execute the deployments. With this refactor, this becomes a pure function with very predictable behavior and no side effects.

DeployPackages

This is the actual deployment. This function calls WindowsAppRuntime::Deployment::PackageRegistrar::AddOrRegisterPackageInBreakAwayProcess or WindowsAppRuntime::Deployment::PackageRegistrar::AddOrRegisterPackage depending on the arguments (in this case, if it is full trust or not). These two functions were moved to the PackageRegistrar namespace as they are similar and very specific on what they intent to do.

Package utilities

The deployment manager's methods related to package querying were moved to a new namespace WindowsAppRuntime::Deployment::Package, on the files PackageUtilities.h|cpp. This was done in case we want to mock this behavior in tests and also for organization purposes.

Unit tests

With this refactoring, I created the new test project DeploymentUnitTests. I wrote some initial tests for both deployer and package registrar namespaces. With more test scenarios also being easily implemented if needed as now the modules are more independent and the major dependencies are broken.

A microsoft employee must use /azp run to validate using the pipelines below.

WARNING:
Comments made by azure-pipelines bot maybe inaccurate.
Please see pipeline link to verify that the build is being ran.

For status checks on the main branch, please use TransportPackage-Foundation-PR
(https://microsoft.visualstudio.com/ProjectReunion/_build?definitionId=81063&_a=summary)
and run the build against your PR branch with the default parameters.

[DrusTheAxe]

If the current application has runFullTrust capability

This is incorrect. RuntimeBehavior="packagedClassicApp" (aka Centennial) needs Breakaway, RuntimeBehavior="win32App" (aka Win32alacarte) doesn't.

[guimafelipe]

Given the scope of this refactor, I’d strongly recommend exercising the functionality manually end to end across all three scenarios as well—packaged, unpackaged, and AppContainer. It would also be valuable to add coverage for AppContainer scenarios and/or sample launch tests, even if that happens in a future PR.

I completely agree that all the scenarios need to be tested and I think we should have all of it automated instead of testing it manually. I think it is a worth effort to ensure it on the goal of reducing all the current errors and crashes from the deployment area.