Si vous livrez une application de bureau Windows, l'étape de packaging est en général la partie la moins intéressante de votre pipeline et celle qui risque le plus de le casser. Le build lui-même est propre. Puis l'étape de packaging réclame makeappx.exe, makeappx.exe vit dans le Windows SDK, et voilà que votre agent de build a besoin d'une installation de SDK de plusieurs gigaoctets, figée sur une version précise, juste pour transformer un dossier en package.
Il existe un moyen de contourner cela, et il n'exige pas d'abandonner les conventions d'outillage que votre pipeline utilise déjà.
Pourquoi la dépendance au SDK est le vrai problème
Le Windows SDK est un outil de poste de développement. Le placer sur un agent de build crée trois coûts récurrents.
Le premier est la taille de l'image et le temps de provisionnement. Un agent hébergé qui doit installer le SDK avant de pouvoir empaqueter paie ce coût à chaque exécution propre. Un agent auto-hébergé qui l'embarque en dur transporte une image bien plus lourde.
Le deuxième est la dérive de version. Le comportement de packaging peut différer d'une version de SDK à l'autre : dès qu'un agent n'a pas le même SDK qu'un autre, vous obtenez un build qui passe sur une machine et échoue sur une autre, pour des raisons qui n'ont rien à voir avec votre code.
Le troisième est le plus gênant. Le SDK représente une surface importante à justifier auprès de la personne qui valide ce qui atterrit sur l'infrastructure de build, et il ne fait qu'une seule chose pour vous : produire un package à partir d'un dossier.
Le moteur de packaging est déjà sur la machine
Le détail important, c'est que le packaging MSIX n'est pas quelque chose que le SDK réalise par lui-même. Le moteur AppxPackaging est un composant de Windows. makeappx.exe est une enveloppe en ligne de commande autour de ce moteur, qui se trouve être livrée dans le SDK.
Cela signifie qu'un outil peut appeler directement le même composant du système d'exploitation. forge_msix, l'interface en ligne de commande d'EtherApps Forge, fait exactement cela. C'est un remplacement direct de makeappx.exe : les mêmes verbes, les mêmes commutateurs, les mêmes attentes sur ce qui entre et ce qui sort. Si votre pipeline appelle aujourd'hui makeappx pack, vous changez le nom de l'exécutable et l'étape continue de fonctionner.
Les verbes compatibles makeappx sont pack, unpack, bundle, unbundle, validate et make-pri. Si tout ce qu'il vous faut est le comportement du SDK sans le SDK sur l'agent, cet ensemble suffit.
Une étape de pipeline minimale
La forme de la chose est banale, et c'est précisément l'intérêt.
# Package a build output folder into an MSIX
forge_msix pack /d .\publish\win-x64 /p .\artifacts\ContosoApp.msix
# Validate before anything downstream touches it
forge_msix validate /p .\artifacts\ContosoApp.msix
Deux choses méritent d'être connues à propos de validate. Il renvoie un code de sortie non nul lorsque le package n'est pas valide, ce qui vous permet de faire échouer le build plutôt que de découvrir le problème au déploiement. Et le code de sortie 2 signifie précisément que le package a été analysé correctement mais qu'il est invalide, par opposition à un outil qui n'a pas réussi à s'exécuter du tout. Traiter ces deux cas différemment dans votre pipeline fait la différence entre une barrière utile et une barrière déroutante.
Signer sans étape manuelle
Le packaging et la signature ont tendance à être séparés parce qu'ils reposent sur des outils différents, et c'est ainsi que des packages non signés finissent par atteindre un anneau de test.
Signer depuis le magasin de certificats par empreinte garde la clé privée là où elle doit rester et conserve un pipeline déclaratif :
forge_msix sign /p .\artifacts\ContosoApp.msix `
/thumbprint <certificate-thumbprint> `
/timestamp http://timestamp.digicert.com
Utilisez un serveur d'horodatage RFC 3161. Sans horodatage, votre package cesse d'être validé dès l'expiration du certificat de signature, alors même qu'il a été signé légitimement pendant la période de validité de celui-ci. Avec un horodatage, la signature reste valide au-delà de la durée de vie du certificat.
Notez que sign fait partie des verbes à valeur ajoutée et non des verbes compatibles makeappx : il exige donc une licence Forge active. Il en va de même pour create, test, assess, les verbes cert- et les verbes dev-.
Raccourcir la boucle interne
La partie la plus lente du travail MSIX n'est en général pas le packaging. C'est la boucle : empaqueter, installer, découvrir qu'il y a un problème, désinstaller, changer une ligne, recommencer.
Les verbes dev-register et dev-test permettent d'enregistrer un package depuis un dossier sans construire et installer un package complet à chaque fois. Pour qui itère sur les capacités du manifeste, les associations de types de fichiers ou les points d'entrée, cela supprime l'essentiel de l'attente.
Publier les mises à jour
Une fois que le pipeline produit et signe des packages, la distribution reste la question ouverte. make-appinstaller génère un flux de mise à jour App Installer, ce qui vous donne une URL que les clients installés interrogent pour trouver de nouvelles versions. Pour un ISV qui livre en dehors d'un parc géré, c'est souvent toute l'histoire de la distribution : publiez le package et le flux, et les installations existantes se mettent à jour d'elles-mêmes.
Où cela se situe
Il s'agit d'un problème différent de celui que traitent la plupart des contenus sur le packaging applicatif. Le scénario habituel est une équipe informatique face à une application dont l'installeur a disparu depuis longtemps et dont l'éditeur d'origine n'existe peut-être plus, ce qui est un problème de capture et de remédiation. Ce travail relève de notre parcours Packaging et déploiement MSIX.
Ce qui est décrit ici suppose l'inverse : il existe un dossier de build en bonne santé, rien n'a besoin d'être capturé, et la friction vient de tout ce qui se passe après la réussite du build. C'est le parcours Packaging MSIX pour les développeurs et les ISV, et il s'adresse réellement à un public distinct, avec des problèmes distincts.
Si vous avez aussi besoin de correctifs de compatibilité pour une application qui se package proprement mais se comporte mal dans le conteneur, la mise en place du Package Support Framework ajoutée dans Forge 1.0.6 est décrite dans les notes de version 1.0.6.
Testez-le sur votre propre pipeline
Le test honnête consiste à vérifier si votre étape de packaging existante continue de fonctionner quand vous changez le nom de l'exécutable. EtherApps Forge est une application de bureau Windows assortie d'un essai gratuit de 7 jours : vous pouvez donc mener ce test sur un vrai build avant de décider quoi que ce soit.
Découvrir le packaging MSIX pour les développeurs et les ISV