ich muss eine neue Version für unser CRM-System paketieren und wechsle bei der Gelegenheit einige Paket-Parameter, da die neue Version ohnehin die vorherige Deinstallation des alten Pakets erfordert.
Altes Paket exklusiv für Empirum → neues Paket direkt mit PSADT
Herstellername mit „AG“ → neuer Name ohne
Die Software erfordert ein paar Systemvoraussetzungen (.NET Framework, Visual C++ redistributables, …) und bekommt direkt noch einige zugehörige Add-Ons an die Seite gestellt, die ebenfalls in einer definierten Reihenfolge gegeben sein müssen bzw. installiert werden.
Im alten Paket meines Vorgängers wurde hier alles in einem Paket verarbeitet, entsprechend mit vielen MSI-GUIDs, Überprüfungen, Log-Files…
Bei einer anderen Software (ebenfalls von vor meiner Zeit) hingegen haben wir die Hauptsoftware und die ganzen Office-Addons als separate Pakete.
Da ich jetzt vermehrt Paketieren muss und ich dann öfters vor der Thematik stehe, würde mich hier das Best Practice aus der Praxis interessieren.
Die grundlegenden Systemvoraussetzungen wie .NET Framework und Visual C++ redistributables würde ich analog zu den APD Paketen direkt ins Paket einbauen, aber bei den anderen bin ich mir unschlüssig, was hier der offizielle/bessere Weg ist.
Für einen Einblick in die langjährige Erfahrung damit wäre ich sehr dankbar.
entschuldige die späte Antwort. Diese Woche war irgendwie jeder Tag ein Montag.
Zum Thema:
Zunächst kannst Du die Voraussetzungen tatsächlich zu großen Teilen einfach vor der Haupt-Installation installieren lassen. .NET Framework würde ich allerdings nicht mit dem Paket selber installieren lassen, da hier fast jede neue Windows Version andere Sourcen benötigt (z.B. Win11 23H2 → Win11 24H2). In unserem „Application Package Depot“ (APD) gibt es daher ein eigenes Paket dafür. In Dein Paket solltest Du dann nur einen Test auf die richtige .NET Framework-Version einbauen.
Für die Prüfung auf .NET Framework und die Installation von Voraussetzungen wäre „Devolutions Remote Desktop Manager“ aus dem APD ein gutes Beispielpaket. Da kannst Du Dir einfach abgucken, wie das umgesetzt werden kann. Wir legen dafür paketspezifische Variablen in der neo42PackageConfig.json an, die dann in der Deploy-Application.ps1 genutzt werden.
Weitere Setups/MSIs kannst Du auf die gleiche Weise hinzufügen. Lege die benötigten paketspezifischen Variablen an (InstFile_[MySetup], InstPara_[MySetup], UninstFile_[MySetup], UninstPara_[MySetup], und ggf. weitere falls benötigt), und füge in den Custom-Bereichen nach der Installation die Benötigten Aufrufe hinzu.
Beispielsweise könntest Du „CustomInstallAndReinstallAndSoftMigrationEnd“ nutzen und da Execute-Process einfügen:
jetzt bin ich diese Woche gesundheitlich raus, wollte aber dennoch eine kurze Antwort da lassen.
Vielen Dank in jedem Fall für die Antwort und die Tipps und Hinweise, definitiv hiilfreich!
Kann ich daraus denn auch ableiten, dass das so zu handhaben dann im Endeffekt auch die empfohlene Art ist, solche großen Pakete zu schnüren?
Habe da einfach noch kein echtes Gefühl dafür und ist bei mir gerade so ein 50:50 Ding.
Alle Addon-Komponenten in separate Pakete outzusourcen würde mehr Pakete/Arbeit bedeuten, aber eben auch mehr Flexibilität im Falle von Updates oder Problemen, die nur eine einzelne Komponente betreffen.
Würde mich gerne direkt beim ersten Paket für die in der Praxis „bessere“ Variante entscheiden und mir rückblickend ein Paket im System ersparen, das ich bereue so gemacht zu haben
Vielleicht findet sich ja noch jemand mit einer Meinung und Argumenten für die eine oder andere Variante.
was die bessere Entscheidung gewesen wäre, weiß man leider oft erst im Nachhinein.
Aber in dem Fall ist die Wahl, es in einem Paket zu machen quasi risikolos. Du kannst die genaue Rehenfolge der Installationenen so einfach festlegen und wenn es einmal getestet ist, fast sicher sein, dass es dann auch funktioniert.
Sollte im Nachhinein ein Update einzelner Komponenten nötig werden, kannst Du das einfach in einem eigenen Paket nachschieben und/oder das Hauptpaket trotzdem aktualisieren.
Da würde ich einfach flexibel auf die Situation reagieren.
Meiner Meinung nach, kann man da nicht so viel falsch machen.
Einfach Pakete erstellen, ordentlich testen und ausrollen…
