Software Update Automatisierung

  • Halli Hallo,

    was macht so ein Thema in "Programmierung"? Naja, ist etwas komplexer das was ich machen will.

    Also kurz Zusammenfassung des Problems:
    Eine Software die effektiv aus mehreren einzeln (und in bestimmter Reihenfolge) zu installierenden Komponenten besteht muss regelmäßig ein Update erfahren. Dabei hat diese Software weitreichende Konfigurationsmöglichkeiten, weswegen die Konfiguration der alten Installation und die der neuen gemerged werden müssen. Am Ende muss das gemergede ganze an Leute ausgerollt werden die von Software keine Ahnung haben.

    Jetzt muss der ganze Vorgang natürlich so wenig arbeitsintensiv und fehleranfällig wie möglich gestalltet werden, muss schließlich auch funktionieren wenn wer anders als ich das macht^^

    Follgende "Eingabedaten" habe ich:

    • Mehrere (interaktive) Installer (.exe Dateien)
    • Mehrere .zip Archive
    • Ein Subversion (SVN) Repo mit der "alten" Konfiguration
    • Eine .7z Datei die den Installationsordner der "alten" Software enthält


    follgendes muss passieren:

    • Aus dem Ergebnis der Installer und den entzipten und umbenannten Inhalten eine neue "blanke" Installation bauen
    • Die alte Konfiguration mit der neuen mergen
    • Den neuen Softwarestand an eine Reihe Rechner verteilen

    Dabei können ein paar Eigenschaften der Installer und der Software helfen:
    Die Software hat im Installationsordner eine sehr klare Trennung zwischen "Kundenkonfiguration" und "Basisinstallation" d.h. über die Ordnerstruktur ist klar was was ist. Von allem was Konfiguration ist existiert auch ein Template (also wenn der Konfig Ordner config heißt gibt es ein template-config, dass eine "vorgeschlagene" Konfiguration enthält) so dass man bei neuen Funktionen auch statt die heftig modifizierte Konfig mit der Standard Konfig zu vergleichen das alte Template mit dem neuen vergleichen kann und so alle Unterschiede bekommt die im Standard vorgenommen wurden. Außerdem kann man die Installer über die alte Installation drüber bügeln wenn man will, dann bleiben alle Konfigordner in ihrem Ursprungszustand erhalten, ansonsten nimmt der Installer eine Kopie des templates als "start Konfig".

    Bisher ging der Prozess so:
    die gesamte Installation wurde in einem SVN gehalten, wer die Installation wollte hat das SVN ausgechecked, für den Update wurde aus einem Entwicklerrepo der "aktuelle" Stand geholt und mit dem Installations SVN komplett von Hand (mit WinMerge) gemerged.
    Das geht inzwischen aus verschiedenen Gründen nicht mehr: 1) auf das Entwickler svn soll nicht zugegriffen werden, das war eh dreckig "gehacked" das wir da überhaupt Zugriff drauf hatten - es sollen die Installer genutzt werden. 2) Alles von Hand mergen ist SEHR Fehleranfällig und hat eine Menge Probleme bereitet. 3) Wir brauchen inzwischen auch die registry Einträge die der Installer setzt, die uns vorher egal waren. Ein einfaches Ordner kopieren tut nicht mehr.

    So und nun sitze ich hier und versuche mir was zusammen zu basteln um das halbwegs sinnvoll zusammen zu bekommen.

    Der Hotfix-Umbau von dem Prozess war: Damit die Idioten die das Mergen machen gar nicht erst auf blöde Ideen kommen nur Dinge im SVN halten die auch wirklich angefasst wurden in der Konfiguration alles andere auf ignore setzen. Alles was Standard ist raus. In einer VM die Installer ausführen, die zips entpacken und dazu schmeißen, dem Installationsordner sagen: du bist übrigens folgendes svn und bitte Revert mal alles (was die Konfig reverted und den Standard behält), dann die template-configs untereinander vergleichen (alte und neue) und ggf. Änderungen übernehmen wenn sie sinnvoll scheinen, aktualisierte Konfig ins svn commiten, die ganze Software als .7z Archiv zusammenpacken. Zum Ausrollen auf den Anderen Rechnern die Installer ausführen (um die registry Einträge etc. zu bekommen), den Installationsordner löschen und durch den Inhalt der 7z Datei ersetzen.

    Info:
    Die Konfig kann sich auch während des gleichen Releases der Software ändern, da schrauben wir permanent drann rum, deswegen muss die in irgendeinem Versionsverwaltungsprogramm liegen.


    So, und nu finde ich, dass das so wie es ist a) zu viel Zeit verbrät und b) zu fehleranfällig ist. Was machen?

    Ich könnte das Installer ausführen und zips entpacken/umkopieren/umbenennen an ein script auslagern, das würde schonmal eine Menge Zeit sparen weil ein großer Teil des Prozesses unbeaufsichtigt laufen könnte. Dann irgendwie automatisiert sagen: wenn alte und neue templates quasi identisch sind (eine Buildnummer wird sich immer unterscheiden) dann behalt einfach deine alte Konfig und nur wo sich was getan hat guck es dir an.
    Aber auch das ausrollen muss schöner gehen.

    all I can do is be me, whoever that is. -Bob Dylan

    Römer sind keine Bieber!

    2 Mal editiert, zuletzt von Giovannie (19. Mai 2017 um 00:25) aus folgendem Grund: Rechtschreibung und Formatierung

  • Also ich wuerde in etwa so vorgehen.

    Step 1
    Regelmaessiges generieren von Paketen aus eurem SVN.
    Somit hast du fertige Zips / whatever von allen Teilen in der Aktuellen version.

    Step 2
    Automatische erfassung der Versionen des aktuellen Systems.

    Step 3
    Automatische generierung der Setup reihenfolge. (evlt handgeschriebe Regeln)

    Step 4
    Automatisches Zusammenstellen des Installerscripts. nr 3 nr 2 nr 5 nr 7 usw.

    Step 5
    nachladen der Pakete / Pakete entpacken

    Step 6
    Automatisches Setup / Mergen

    oder taeusche ich mich?

  • Continuous Integration Server nutzen. Da kannst du dann auch gleich Testfälle/Validierungen einrichten. Ich kenne sowas nur von der Adminseite (Jenkins Server), nicht von Entwicklerseite, aber ich denke das könnte das Werkzeug sein, das du suchst. Ist halt ein Monster, aber wir nutzen das zum automatisierten Bauen und Validieren von Android Applikationen, am Server laufen automatisierte Tests mit Android VMs bzw. per USB angeschlossenen Testtelefonen. Jenkins checkt laufend aus SVN neu aus, wenn es Commits gibt, tracked welcher User fehlerhaften Code committed hat und in welcher Revision usw...

    Damit kannst jedenfalls ein vollautomatisches Build- und Testsystem realisieren. Fehler sind sofort am Webinterface ersichtlich, inkl. Konsolenoutputs wo sinnvoll.

    Kannst ja Mal schauen ob das nicht was für dich ist. Initial ist der Aufwand halt hoch, aber wenn's Mal rennt...

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

  • Bier, du beschreibst nur den kleineren Teil des Problems. Am Ende habe ich eine fertige Version die ich nicht gescheit ausrollen kann.

    Ein einfaches automatisieren vom Installer + sonstige Pakete um dann die neue Version (inkl. Merge) schneller/einfacher hin zu bekommen ist das minimum aber löst nur einen Teil vom Problem.

    @Jenkins: Ich kannte sowas sonst bisher nur um meine Java/Maven Projekte automatisch bauen und testen zu lassen, keine Ahnung ob/welcher dieser Server da gescheite Funktionalität in die Richtung hat die ich will, das könnte in der Tat einiges vereinfachen. Dann bleibt aber immer noch das Problem wie Rolle ich die neue (gemergete) Version am gescheitesten aus.

    all I can do is be me, whoever that is. -Bob Dylan

    Römer sind keine Bieber!