Softwarepaketierung
Nichts erfinden: vier Regeln, nach denen AppCloud365 Pakete baut
Ein Paket, das im Deployment still scheitert, kostet mehr als eines, das gar nicht gebaut wird. Warum wir Hashes prüfen, Kommandos nie raten, Tooling nur aus offiziellen Quellen beziehen und Exit-Codes unverändert melden.
Es gibt eine Sorte Fehler, die im Paketierungsalltag besonders teuer ist: das Paket, das erfolgreich aussieht. Der Job meldet „fertig“, das Deployment meldet „installiert“, und drei Tage später stellt sich heraus, dass die Deinstallation nie funktioniert hat oder der Installer gar nicht der war, den man meinte. Als wir AppCloud365 entworfen haben, war uns wichtiger, dass so etwas nicht passiert, als dass jede Anwendung auf Knopfdruck durchläuft. Daraus sind vier Regeln geworden.
Regel 1: Kein Download ohne Hash
Jedes Manifest im WinGet-Katalog enthält die SHA-256-Prüfsumme des Installers. AppCloud365 lädt die Datei vom Server herunter, berechnet den Hash beim Empfang und vergleicht ihn mit dem Manifest. Stimmt er nicht, wird die Datei verworfen und der Job schlägt mit einer klaren Meldung fehl. Die Datei wird in diesem Fall nie ausgeliefert, auch nicht „zur Ansicht“.
Dazu kommen Regeln, die man erst vermisst, wenn sie fehlen: Downloads nur über HTTP und HTTPS, keine Zugangsdaten in URLs, keine Verbindungen zu privaten Netzbereichen, Größenlimits, Zeitlimits, und Dateinamen, die aus der URL oder dem Server kommen, werden bereinigt, bevor sie auf der Platte landen.
Regel 2: Kommandos werden nicht geraten
Die zweite Regel klingt banal und ist die schwierigste: Install- und Uninstall-Kommandos entstehen ausschließlich aus Manifestdaten und aus dem, was über die Installer-Familie sicher bekannt ist.
Ein MSI bekommt msiexec.exe /i mit den Silent-Parametern. Die Deinstallation gibt es nur, wenn ein gültiger GUID-ProductCode vorliegt; dann lautet sie msiexec.exe /x "{GUID}" /qn /norestart. Inno-Setup- und Nullsoft-Installer bekommen die dokumentierten Standard-Switches ihres Frameworks, sofern das Manifest keinen eigenen nennt. Ein EXE-Installer ohne bekannten Switch bekommt ein Kommando ohne Switch, ausdrücklich als unsicher markiert. Und wenn sich kein Deinstallationsbefehl ableiten lässt, sagt der Assistent das: „Uninstall command could not be determined automatically.“ Dann geben Sie ihn ein oder bestätigen ausdrücklich, dass das Paket keinen hat.
Was es nicht gibt: einen ProductCode an einem EXE-Installer, der automatisch zu einem msiexec /x wird. Das wäre eine Vermutung, und Vermutungen sind in einem Deployment-Skript nichts wert.
Regel 3: Tooling nur aus offiziellen Quellen
PSAppDeployToolkit und das Microsoft Win32 Content Prep Tool sind fremde Software. AppCloud365 lädt sie nie zur Laufzeit herunter. Ein separater Bootstrap holt die jeweils aktuelle stabile Version aus den offiziellen Repositories, prüft Release-Status, Dateigröße, Archivinhalt und Pflichtdateien, und legt sie außerhalb des Web-Verzeichnisses ab. Vorabversionen werden übersprungen. Fehlt das Tooling, zeigt die Oberfläche die betroffenen Paketoptionen als nicht verfügbar an, statt ein Paket ohne Toolkit zu bauen.
Regel 4: Exit-Codes werden nicht schöngeredet
Der native Wrapper ohne PSADT führt das bestätigte Kommando aus und reicht das Ergebnis weiter. Als Erfolg gelten die Exit-Codes 0, 3010 (Neustart empfohlen) und 1641 (Neustart eingeleitet). Jeder andere Code wird unverändert als Fehler gemeldet. „Unbekannt bedeutet okay“ gibt es nicht. Ohne bestätigten Deinstallationsbefehl erzeugt Uninstall.ps1 bewusst einen Fehler mit der Meldung, dass der Befehl nicht ermittelt werden konnte, damit das Deployment-Reporting die Lücke zeigt.
Beim Bau selbst gilt dasselbe Prinzip: Ein Lauf, der scheitert, erzeugt kein Paket. Die erste aussagekräftige Meldung des Werkzeugs landet in der Fehlermeldung des Jobs, nicht in einem Protokoll, das niemand öffnet.
Warum das Tempo kostet und trotzdem schneller ist
Diese Regeln bedeuten, dass AppCloud365 manche Anwendung nicht vollautomatisch paketiert. Ein portables Programm ohne Manifestdaten bekommt nur den Original-Download, ein exotischer Installer verlangt einen manuellen Deinstallationsbefehl. Das ist Absicht. Die Zeit, die das kostet, ist die Zeit, die ein Paketierer ohnehin investieren müsste, nur früher und sichtbar. Die Zeit, die es spart, ist die Nacht, in der zweihundert Geräte ein Paket melden, das nur so aussah, als hätte es funktioniert.
Alle Abbildungen zeigen die tatsächliche Anwendung mit fiktiven Demodaten.