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.