Wenn Sie eine Windows-Desktop-Anwendung ausliefern, ist der Paketierungsschritt meist der uninteressanteste Teil Ihrer Pipeline und zugleich derjenige, der sie am ehesten zerlegt. Der Build selbst ist sauber. Dann braucht die Paketierungsstufe makeappx.exe, makeappx.exe liegt in der Windows SDK, und plötzlich braucht Ihr Build-Agent eine mehrere Gigabyte große SDK-Installation, festgenagelt auf eine bestimmte Version, nur um aus einem Ordner ein Paket zu machen.
Es gibt einen Weg daran vorbei, und er verlangt nicht, dass Sie die Werkzeugkonventionen aufgeben, die Ihre Pipeline bereits nutzt.
Warum die SDK-Abhängigkeit das eigentliche Problem ist
Die Windows SDK ist ein Werkzeug für Entwickler-Arbeitsplätze. Auf einen Build-Agent gepackt verursacht sie drei wiederkehrende Kosten.
Die erste ist Image-Größe und Bereitstellungszeit. Ein gehosteter Agent, der die SDK erst installieren muss, bevor er paketieren kann, zahlt diese Kosten bei jedem sauberen Lauf. Ein selbst gehosteter Agent, in dessen Image sie fest eingebacken ist, schleppt ein deutlich größeres Image mit sich.
Die zweite ist Versions-Drift. Das Paketierungsverhalten kann sich zwischen SDK-Versionen unterscheiden. Sobald also ein Agent eine andere SDK hat als ein anderer, bekommen Sie einen Build, der auf der einen Maschine durchläuft und auf der anderen scheitert, aus Gründen, die nichts mit Ihrem Code zu tun haben.
Die dritte ist die unangenehme. Die SDK ist eine große Fläche, die Sie gegenüber derjenigen Person rechtfertigen müssen, die freigibt, was auf die Build-Infrastruktur kommt, und sie erledigt genau eine Aufgabe für Sie: aus einem Ordner ein Paket zu erzeugen.
Die Paketierungs-Engine liegt bereits auf der Maschine
Das wichtige Detail ist, dass MSIX-Paketierung nichts ist, was die SDK aus eigener Kraft erledigt. Die AppxPackaging-Engine ist ein Bestandteil von Windows. makeappx.exe ist ein Kommandozeilen-Wrapper darum, der zufällig mit der SDK ausgeliefert wird.
Das heißt, ein Werkzeug kann dieselbe Betriebssystemkomponente direkt aufrufen. forge_msix, die Kommandozeilen-Schnittstelle in EtherApps Forge, tut genau das. Es ist ein Drop-in-Ersatz für makeappx.exe: dieselben Verben, dieselben Schalter, dieselben Erwartungen daran, was hineingeht und was herauskommt. Ruft Ihre Pipeline heute makeappx pack auf, ändern Sie den Namen der ausführbaren Datei und die Stufe läuft weiter.
Die makeappx-kompatiblen Verben sind pack, unpack, bundle, unbundle, validate und make-pri. Wenn Sie nur das SDK-Verhalten brauchen, ohne die SDK auf dem Agenten zu haben, deckt dieser Satz das ab.
Eine minimale Pipeline-Stufe
Die Form der Sache ist unspektakulär, und genau darum geht es.
# 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
Zwei Dinge sollten Sie über validate wissen. Es gibt einen Exit-Code ungleich null zurück, wenn das Paket nicht gültig ist, und genau das erlaubt Ihnen, den Build scheitern zu lassen, statt das Problem erst beim Deployment zu entdecken. Und Exit-Code 2 bedeutet konkret, dass das Paket erfolgreich analysiert wurde, aber ungültig ist, im Unterschied dazu, dass das Werkzeug überhaupt nicht laufen konnte. Diese beiden Fälle in Ihrer Pipeline unterschiedlich zu behandeln ist der Unterschied zwischen einem nützlichen und einem verwirrenden Gate.
Signieren ohne manuellen Schritt
Paketierung und Signierung werden gerne voneinander getrennt, weil sie unterschiedliche Werkzeuge nutzen, und so landen unsignierte Pakete am Ende in einem Test-Ring.
Das Signieren aus dem Zertifikatsspeicher per Thumbprint hält den privaten Schlüssel dort, wo er hingehört, und die Pipeline deklarativ:
forge_msix sign /p .\artifacts\ContosoApp.msix `
/thumbprint <certificate-thumbprint> `
/timestamp http://timestamp.digicert.com
Nutzen Sie einen RFC 3161-Zeitstempelserver. Ohne Zeitstempel hört Ihr Paket in dem Moment auf zu validieren, in dem das Signaturzertifikat abläuft, obwohl es rechtmäßig signiert wurde, während das Zertifikat gültig war. Mit Zeitstempel bleibt die Signatur über die Lebensdauer des Zertifikats hinaus gültig.
Beachten Sie, dass sign zu den Mehrwert-Verben gehört und nicht zu den makeappx-kompatiblen, es braucht also eine aktive Forge-Lizenz. Dasselbe gilt für create, test, assess, die cert--Verben und die dev--Verben.
Die innere Schleife verkürzen
Der langsamste Teil der MSIX-Arbeit ist meist nicht die Paketierung. Es ist die Schleife: paketieren, installieren, feststellen, dass etwas nicht stimmt, deinstallieren, eine Zeile ändern, von vorn.
Mit den Verben dev-register und dev-test registrieren Sie ein Paket aus einem Ordner, ohne jedes Mal ein vollständiges Paket zu bauen und zu installieren. Wer an Manifest-Capabilities, Dateitypzuordnungen oder Einstiegspunkten iteriert, spart damit den größten Teil der Wartezeit.
Updates veröffentlichen
Sobald die Pipeline Pakete erzeugt und signiert, bleibt die Verteilung als offene Frage. make-appinstaller erzeugt einen App Installer-Update-Feed und damit eine URL, unter der installierte Clients auf neue Versionen prüfen. Für einen ISV, der außerhalb einer verwalteten Umgebung ausliefert, ist das oft die gesamte Verteilungsgeschichte: Paket und Feed veröffentlichen, und bestehende Installationen aktualisieren sich selbst.
Wo das hineinpasst
Das ist ein anderes Problem als jenes, das die meisten Inhalte zur Anwendungspaketierung behandeln. Das übliche Szenario ist ein IT-Team vor einer Anwendung, deren Installer längst verschwunden ist und deren ursprünglicher Hersteller womöglich nicht mehr existiert, also ein Capture- und Remediation-Problem. Diese Arbeit liegt auf unserer Route MSIX-Paketierung und Deployment.
Was hier beschrieben wird, setzt das Gegenteil voraus: Es gibt einen gesunden Build-Ordner, nichts muss erfasst werden, und die Reibung entsteht durch alles, was nach dem erfolgreichen Build passiert. Das ist die Route MSIX-Paketierung für Entwickler und ISVs, und sie richtet sich wirklich an ein eigenes Publikum mit eigenen Problemen.
Wenn Sie zusätzlich Kompatibilitäts-Fix-ups für eine Anwendung brauchen, die sauber paketiert, sich im Container aber danebenbenimmt: Die in Forge 1.0.6 ergänzte Bereitstellung des Package Support Framework ist in den Release Notes zu 1.0.6 beschrieben.
Testen Sie es an Ihrer eigenen Pipeline
Der ehrliche Test ist, ob Ihre bestehende Paketierungsstufe weiterläuft, wenn Sie den Namen der ausführbaren Datei ändern. EtherApps Forge ist eine Windows-Desktop-Anwendung mit einem kostenlosen 7-Tage-Test, Sie können diesen Test also an einem echten Build durchführen, bevor Sie irgendetwas entscheiden.